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ABSTRACT 


CyberCIEGE aims to provide an Information Assurance (lA) teaching/learning 
Eaboratory in the form of an interactive, entertaining, commercial-grade PC-based 
computer game. Each game plays as a single scenario that serves to teach a particular lA 
concept. However, more synergy can be gained if there is higher-order organization of 
these scenarios, such as by grouping around a set of desired concepts to be taught, or by 
increasing the complexity of the scenarios built around a common theme. This thesis 
aims to provide an instructor tool for this purpose. 

In addition, by tapping the CyberCIEGE event log files generated at the end of 
each game, we can reconstruct the game progress to support After Action Reviews (AAR) 
to assist the instructor and student to analyze game decisions and the student’s learning 
progress. This provides a constructive follow-up to review and reinforce the concepts 
being taught. 
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I. INTRODUCTION 


A. BACKGROUND 

As mentioned by [Salzer 1975], security is often viewed as “a negative kind of 
requirement”. It is not uncommon that when faced with resource and schedule demands, 
security is often one of the first victims of project management prioritization. The 
consequences of such decisions are often not seen until the system has gone into 
operation. The impacts are only felt when security flaws are subsequently exploited or 
perceived to be exploitable. Traditional information systems have often seen security 
issues addressed only as an after thought, with dramatically disastrous effects. Attempts 
at conducting security analysis at that point are especially hard, as the system has become 
monolithic with hundreds of thousands of lines of codes to be analyzed. Post¬ 
implementation defects eventually lead to demands for numerous ad-hoc patches and 
consequent system down times. On occasions, hastily but poorly tested patches have 
themselves contributed to introducing further flaws, with patches requiring patches 
[Livingston 2003], and in some cases exploited by unskilled vandals (e.g. “script- 
kiddies”). 

Recognition of the needs for well-designed information security have been 
recognized as early as the 70s, as exemplified by the [Anderson 1972] study and the 
[Saltzer 1975] paper. In the military arena, increasing dependence and use of information 
technology, initially for combat support operations, and in more recent times as integral 
components of Command, Control and Communication (C3I) and Intelligence, 
Surveillance and Reconnaissance (ISR) systems have elevated the importance of 
information security. Military operations that have traditionally been conducted only in 
the physical space are rapidly moving into the information space as well. To this end, the 
US Joint doctrine for Information Operations (10) [Joint 1998] recognizes Information 
Assurance (lA) as one of the key tenets of an effective 10 strategy. As defined in [Joint 
1998], lA is ‘TO that protect and defend information systems by ensuring their 
availability, integrity, authentication, confidentiality and non-repudiation”. It includes 
provision for restoration of information systems incorporating protection, detection and 
reaction capabilities (see Figure 1). 
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Figure 1. Information Operations relationships across time. (From [Joint 1998]) 

As part of an effective implementation plan to further this, it is important to 
promote awareness of security issues to a wide spectrum of users. Information systems 
are today reaching a wide spectrum of users. Unfortunately, it is rare for non-security 
inclined personnel to possess a natural inclination to take an active interest in lA issues. 
How then can we overcome this gap? lA implementations face challenges in terms of 
commitment and conformance, this could lead to less effective implementations, resulting 
in an overall less effective operational lA posture. 

An effective means for conducting training and education and to promote 
awareness in lA is hence crucial. As highlighted by [Tanner 2002], commercial and 
federal systems are targets of attack by criminals and foreign intelligence agencies. 
Technical protection measures alone are insufficient to defend against these as human 
errors and operators errors may leave systems open to other forms of attacks. 
Consequently, security education, training and awareness constitute an integral part of 
any effective layered defense strategy [DON 2000, Boyce 2002]. Usually, this involves 
taking away the warfighter’s precious time from his/her operational functions to attend 
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security awareness training. This is both costly and time-consuming. In addition, it is 
extremely difficult to conduct such training in a manner that would actually captivate the 
student’s attention and interest, and hence improve on the retention of knowledge. 

A novel alternative is to package the training in the form of interactive games. To 
this end, NFS is leading the effort in the development of CyberCIEGE, which could 
significantly contribute towards this goal. America’s Army has paved the way in 
demonstrating the viability of using commercial-grade games to support a learning¬ 
teaching objective [USArmy 2003] as have other similar efforts, demonstrated by the 
Singapore Armed Forces [DSTA 2003], in utilizing games to supplement conventional 
training. 

CyberCIEGE (see Figure 2), originally conceived as “SimSecurity”, aims to 
provide an lA teaching and learning laboratory in the form of an interactive and 
entertaining commercial-grade PC-based game. It is conceived as a real-time interactive 
game with each scenario serving to teach one or more lA concepts. Through playing the 
game, the student gains insight into lA. The CyberCIEGE game itself is being developed 
by Rivermind, Inc. 



Figure 2. CyberCIEGE. 
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B. SCOPE 

The scope of this thesis is to develop on top of the CyberCIEGE effort, to attempt 
to answer the following questions: 

1. How do we construct and organize scenarios to provide an educational 
focus on an lA-specific topic? 

2. What do we need in order to perform student assessment of the scenarios 
played? 

3. What interfaces must be introduced into CyberCIEGE to achieve this? 

To explore to these questions, this thesis involves the analysis, design and 
implementation of instructor tools while concurrently defining the necessary interfaces. 
The instructor tools would enable the construction of campaigns by assembling a 
collection of CyberCIEGE scenarios and provides a means for reviewing student 
performance on the scenarios played. 

In CyberCIEGE, each game plays as an individual scenario that serves to teach a 
particular lA concept. However, more synergy can be gained if there is a higher-order 
organization of these scenarios, such as by grouping around a set of desired concepts to 
be taught, or by increasing the complexity of the scenarios built around a common theme. 
Such a concept has been demonstrated in numerous strategy and action games such as 
Warcraft, Starcraft, Warlords, etc. Rather than working with isolated scenarios, the 
instructor can construct the scenarios to enable the student to progress from one scenario 
to another in a logical fashion. In this manner, a library of scenarios can be reused and 
readily assembled to craft different packages for different teaching objectives. We shall 
refer to these as campaigns. Campaigns can then be customized to meet specific training 
objectives and improve the relevance for the targeted student audience. A tool is hence 
needed to enable the instructor to construct these campaigns. Such a tool is currently not 
within the development scope of CyberCIEGE being undertaken by Rivermind. 

Similarly, within the game being developed by Rivermind, there is little or no 
opportunity for the instructor to review the game played by the student unless the 
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instructor is physically present and observes the progress of game play. Such an 
approach is clearly not preferred and would defeat the objective of a virtual laboratory. 
On the other hand, if the game play could be instrumented and significant events are 
logged, the logs can then be used to analyze game decisions and the student’s progress. 
This approach would enable After Action Reviews (AAR) to be carried, enabling the 
instructor to provide the student constructive follow-up reviews and to further reinforce 
the concepts being taught [DOA 1993, Morrison 1999]. 
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II. REQUIREMENTS 


A. EXISTING PRODUCTS 

A search for existing games of a similar genre reveals the existence of 
CyberProtect and the Information Security Wargaming System (ISWS) described in 
[Saunders 2003] and A/ Wars: The Awakening [Nexus 2003]. 

I. CyberProtect 

CyberProtect is a turn-based game sponsored by the Office of the Assistant 
Secretary of Defense for C3I and the lA Program Management Office of the Defense 
Information Systems Agency (DISA). The game simulates a fairly simple, small 
networked system with interconnections to other departmental systems, external sites and 
the Internet. The game features an introductory tutorial to guide new players through the 
basic of the game’s mechanics and a small reference guide to explain the purpose of each 
of the countermeasures tools available. CyberProtect is fairly easy to learn, and with 
these tools, new players can get going very quickly. 



* Screenshot from CyberProtect. 

Figure 3. CyberProtect - tools acquisition screen. 
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It is played over four quarters (i.e. turns) and revolves around the acquisition and 
deployment of a limited set of abstract defensive information assurance measures which 
are applied to a network of computers at the start of each quarter, as illustrated in Figures 
3 and 4. These measures include training, redundant systems, access controls, virus 
protection, backups, encryption, firewalls and intrusion detection systems, all with 
varying levels of quality and effectiveness (i.e. low, medium or high), and cost. Given a 
limited operating budget in the form of Resource Units (RUs), the player never has 
enough to buy everything desired and careful choices would have to be made. The 
acquired tools are then deployed on the various elements of the networked system. 



* Screenshot from CyberProtect. 

Figure 4. CyberProtect - system with countermeasures applied. 

The networked system is then subjected to a variety of randomly generated 
attacks at the end of each quarter. Specifically, these attacks include jamming, virus 
infections, moles (insider actions), social engineering, packet sniffing, theft, 
modification, spoofing and disaster effects (e.g. flooding). Each attack is evaluated 
against the defensive counter-measures in place to determine the extent of success or 
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failure of system penetration. Feedback is provided indicating the type of attack, origin 
(which external site or insider) and status of the attack (successful or failed). A 
multimedia narration of the attack is also available. With these clues, the player can then 
reexamine the existing countermeasures implemented to figure out why the attacks were 
successful and proceed to acquire further measures or upgrade existing ones to better 
improve the defensive posture. 

At the end of the quarter, a summary and score of the player’s progress is given. 
Success in the game is defined as achieving a final score of 90 or more, thus providing a 
quantifiable measure. 

2. Information Security Wargaming System (ISWS) 

ISWS, developed by Concurrent Technologies Corporation (CTC) for the 
National Defense University, is a tutorial type simulation that provides in-depth focus on 
specific attacks, primarily centered on network-based attacks, and the applicable 
defensive measures. The package has the following teaching objectives: 

• Understand network configuration to defend against attacks. 

• Identify and recommend countermeasures to network attacks. 

• Identify types of security measures to protect and maintain data integrity. 

• Make better strategic decisions related to the protection of network 
attacks. 

A short tutorial guides the student through the various phases of implementing the 
defenses and the tutorial functionalities (see Figure 5). 
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* Screenshot from ISWS. 

Figure 5. ISWS - tutorial. 

The various forms of attacks are grouped into 10 classes, namely - disruption, 
modification, destruction, infection, intrusion, theft/fraud, exploitation and observation. 
From each class of attacks, the student selects a specific attack and ISWS will explain the 
behavior of a system when subjected to such an attack (Figure 6). The student can then 
choose from a list of defensive options to be employed. ISWS presents a fairly detailed 
explanation of the pre-conditions and behavior of a system when undergoing the attack 
using multimedia presentations. 

The student then proceeds to select from a palette of safeguards for each phase 
against the specific attack. These phases include protection, detection, assessment, 
recovery and treatment. When applied, the system assesses and provides feedback on the 
effectiveness of the set of safeguards selected. The student is free to examine various 
what-if combinations of safeguards or to proceed to the next phase. 

Upon completing the phases, the student is presented with the “official” solution. 
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* Screenshot from ISWS. 

Figure 6. ISWS - attack scenario. 

3. Artificial Intelligence (AI) Wars: The Awakening 

AlWars [Nexus 2003] is a futuristic first-person 3D real-time action-strategy 
game published by Nexus Interactive Studios Inc. It is targeted at the gaming community 
and is intended purely for its entertainment value only. 

The player has to conduct research in various areas in order to gain more powerful 
or better software and hardware. In order to understand the cyber-environment, referred 
to as the Net, the player has to map out the different systems and gather datablocks to sell 
or to keep. The player possesses various defensive (e.g. Masquerade, Firewall, Antivirus, 
Spoof, etc) and offensive (Crack, Viral Infections, Infinite Recursive Calculations (IRC), 
etc) options with which to interact within the Net. 

Characters with different predispositions (i.e. usually friendly, sometimes 
unfriendly) exist in the NET and they can be interacted with. However, if the player goes 
into a system and starts attacking a Warden character, the player’s name will be placed in 
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a hacker log. The next time that the player enters the system, the player would be 
attacked on sight. 

A system is divided into public (e.g. online stores, public datastores, news groups 
and chat rooms) and private nodes (e.g. system cores, secure datastore and private 
meeting rooms) with passwords required for gaining entry into a private node. Private 
nodes are further guarded by a Warden. Without the password, the player can force an 
entry by launching the Crack software against the Warden. Attempts at such password 
cracking can trigger an alarm and result in detection. The latter can be mitigated if the 
player pre-activated the Masquerade software, otherwise the Warden will launch an 
active alarm and record the player as an intruder. Subsequent character interactions 
within the system would be hostile and system elements will attempt to eradicate the 
player. To clear the alarms, the player has to reach the system’s Core and interface with it 
to plant a Backdoor. 



Figure 7. AlWars - Inside a Router. (From [Nexus 2003]). 


Success in the game is achieved in any one of three ways: taking control of the 
net, transferring the player’s consciousness and memories into the Net to achieve 
immortality or by bringing the player’s agent to sentience. Taking control of the Net 
requires that the player place a Backdoor in the Core of each of the key systems. The 
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immortality option requires development of six specific technologies, while the agent 
sentience option requires a different set of 4 technologies and acquisition of a lot of data 
for the agent to evolve. 

B. BROAD DESIGN OBJECTIVES 

[Tanner 2002] hypothesized that simulation-based computer security awareness 
training can be more focused and less expensive than a lecture- or laboratory-based 
courses. The design objectives of such a class of tool are defined as follows: 

1. Content: Understand the Threat 

The first step is to know the enemy who may range from novice hackers and 
script-kiddies to state-sponsored organized hackers. Novice hackers typically employ 
readily available tools to exploit known system vulnerabilities. Although pervasive, 
these are relatively easily mitigated. In contrast, state-sponsored organized hackers are 
patient, methodical and not limited to well-known vulnerabilities and readily available 
attack tools. Their activities tend to be covert and not easily detectable. 

2. Content: Awareness of Known Weakness and Attack Techniques 

The objective for the student is to learn about the weaknesses of a networked 
computer system and understand how these may be exploited by hackers. The student 
should be aware of which vulnerabilities can be eliminated and which are unavoidable 
exposures inherent in the design of the system. 

3. Pedagogy: Support Multiple Training Objectives 

The purpose of awareness training is to train the student. To achieve this goal, 
the following training objectives may be relevant: 

a. Connecting concepts to practice. 

b. Repeatability. 

c. Progressing from novice through more sophisticated scenarios. 

d. Examining “what if’s” by reconfiguring and trying again. 

e. Practicing skills in a realistic training environment. 

f. Developing problem-solving and decision-making skills. 
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g. Learning to recognize operational indicators of normal, abnormal 
and emergency conditions. 

4. Pedagogy: Support Multiple Perspectives 

A crucial pedagogical need is to enable the student to understand the cause-and- 
effect relationships, and to examine them from the perspective of the attacker, defender 
or the forensic analyst. 

5. Content: Model the Trainee’s Environment 

By matching the simulated environment with the trainee’s operational 
environment, the training can be more relevant, in-depth, focused and effective. 

6. Portable, Self Contained Laboratory 

As mentioned before, pulling a warfighter from his/her primary operational duty 
for training consumes valuable time and usually undesirable. By making the tool 
portable and self-contained, it can significantly expand the reach of the tool by placing it 
in the hands of the student and enable training at their convenience. 

C. COMPARATIVE REVIEW 

With the objectives thus defined by [Tanner 2002], we will now re-examine the 
three games discussed earlier. Each of the three games described are distinctly different 
but each has some significant attributes that would contribute towards the objective of 
education, training and awareness in information assurance. We shall highlight their 
respective strengths and weaknesses here. 

CyberProtect is a turn-based game which provides a macro view of resource 
management and deployment of abstract defensive countermeasures at a system-level. It 
attempts to teach some broad concepts such as the need for multiple layers of defenses 
and introduces the various forms of general attacks, including social engineering which is 
sometimes not apparent. Correctness of concepts is fairly high, although at a fairly 
abstract level. The abstraction simplifications do help to make the game easy to learn and 
play. Unfortunately, the canned environment presented (i.e. the fixed network) offers 
little replay value and the player will soon run out of concepts to explore. 

ISWS is a tutorial based multimedia package which takes a detail look at each of 
the network-based exploitations. It is clearly focused on teaching the student specific 
forms of attacks in isolation and the ways to mitigate each of them. The what-if’s option 
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in selecting a package of safeguards affords the student some room for exploration. 
However, it does not provide a temporal element and the effects of organized multi¬ 
faceted attacks. The general lack of interactivity between the student and the game 
would soon turn it into a typical multimedia presentation. Certainly, it offers the least in 
terms of replay value. 

AlWars is a real-time 3D entertainment game. In this respect, its re-playability is 
probably the highest and is most likely to captivate the student/player. It clearly carries 
across numerous concepts although the concepts are significantly dramatized for 
increased playability and hence requires the student to be able to relate the corresponding 
metaphors with current realities. 



CyherProtect 

ISWS 

AlWars 

Format 

Educational game. 

Tutorial. 

Entertainment game. 

Understanding of the 

threat 

Yes, but it is not clear 

what the organizational 

security policy is? 

Yes, but addresses each 

form of attack only in 

isolation. 

Uncertain. 

Awareness of known 

weaknesses and attack 

techniques 

Yes. 

Yes. 

Yes. 

Connecting concepts to 

practice 

Yes, at a system-level. 

Yes, for network- 

specific attacks. 

Yes, at a system-level. 

Repeatability 

Limited replay value. 

Low. 

High. 

Progression from 

novice attacks to more 

sophisticated versions 

No. 

No. 

No. 

Examine “what if’s” 

Limited ability. 

Yes, only with respect to 

a single attack type. 

Yes. 

Realistic training 

environment 

Yes. 

Somewhat. 

Generally no, as it uses 

futuristic connotations. 

Develop prohlem- 

solving and decision¬ 
making skills 

Yes. 

Yes, but constructs are 

canned. 

Yes. 
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Learn to recognize 

operational indicators 

Limited. 

No. 

Yes. 

Support for multiple 

perspectives 

No. Only defender’s 

view point is supported. 

No. Only defender’s 

view point is supported. 

Somewhat, as both 

attacker and defender 

perspectives are played. 

Model the student’s 

environment 

No. 

No. 

No. 

Portable, self- 

contained laboratory 

Yes. 

Yes. 

Yes. 


Table 1 Comparison of products reviewed. 


CyberProtect provides a summary score at the end of each quarter and at the end 
of the game, thus providing a quantifiable measure. Unfortunately, the player is not 
provided with any indication of the intended security policy. For instance, there is no 
notion of what resources are being protected, and what the threat is. Consequently, the 
player is left clueless regarding the appropriate strategy to apply. Thus the score does not 
provide any obvious relationship to the success of the security measures implemented. 

From actual games played, the scores do not appear to be useful for comparative 
purposes. One can apply very few and poor measures and yet achieve a score of 99, 
while in another game, despite applying similar measures, a player can score as badly as 
60. The wide variance stems from the randomness of the attacks. A player who happens 
to be subjected to an attack for which a defensive measure happens to be already in place 
will fare very well. In a separate run with the same measures in place, the player may be 
faced with a flood of attacks for which the same measures are unfortunately ineffective. 
In this case, the player will fare very poorly. Hence the resultant score does not serve as 
a useful measure of effectiveness and no real conclusions can actually be drawn. 

ISWS on the other hand, only addresses the security objective from the narrow 
viewpoint of defending against a single threat. Hence, it does not provide a holistic view 
at an organizational level. 

Both CyberProtect and ISWS are fairly restrictive in terms of options and 

flexibility. As the game scenarios are fairly static, there is little room for exploration and 

replay value is limited. CyberProtect for instance, has only a single scenario, although 
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randomized attacks generated do create variety. ISWS has no variations at all and plays 
in a strictly tutorial-like fashion. Both these games do have a very strong flavor of truism 
to the concepts being taught and are therefore high in educational value. 

AlWars’ 3D real-time environment is clearly a step above both CyberProtect and 
ISWS in terms of gaming playability and hence the potential ability to captivate the 
player. Replay value is high; however, this is achieved at the sacrifice of realism. 

D. CYBERCIEGE 

CyberCIEGE, as described in [Irvine 2003], simulates a range of scenarios 
involving networked computer systems with the player assuming the defender role and 
the computer assuming the attacker role. The player needs to construct computer 
networks with components such as servers and workstations, and apply appropriate 
security measures to ensure that the system’s security posture is able to meet the 
organizational goals. The game lies in the tension created by the competing goals of 
efficient and affordable access to assets and protection of assets from unauthorized 
disclosures or modification. This is a significant improvement over that of CyberProtect 
which had only considered the application of protection mechanisms without clearly 
articulating the organization goals. 

Unlike CyberProtect which has a canned scenario, CyberCIECE has a wider 
range of options, allowing the player to construct, interconnect and apply protection of 
the network as well. The player will make decisions that affect the behavior of a set of 
virtual user characters. Hostile game characters may develop and attack the system, 
ranging from vandals, disgruntled insiders, incompetent users, to professional attackers. 
This offers a much richer set of attacks than when compared to CyberProtect. 

[Irvine 2003] puts up a case to illustrate the feasibility of having a computer 
security game that can be both fun and educational. Indeed, CyberCIEGE shares many of 
the playability attributes of AlWars. Both cast the player into a real-time 3D game world 
where the player has to interact with a constantly changing environment. In 
CyberCIEGE, the player starts the game with a finite budget and has to perform resource 
management to establish an ever-growing enterprise, reaping the benefit of productive 
users while balancing benefits of protecting their assets against attackers. The resource 
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management aspects are far more dynamic than that in CyberProtect and are probably 
closer to that of AlWars. 



CyberCIEGE 

Format 

Educational and entertainment 

game. 

Understanding of the threat 

Yes. 

Awareness of known weaknesses and attack techniques 

Yes. 

Connecting concepts to practice 

Yes. 

Repeatability 

Yes. 

Progression from novice attacks to more sophisticated versions 

No. 

Examine “what if’s” 

Yes. 

Realistic training environment 

Yes. 

Develop prohlem-solving and decision-making skills 

Yes. 

Learn to recognize operational indicators 

Yes. 

Support for multiple perspectives 

No. Only defender’s view point is 

supported. 

Model the student’s environment 

Possibly. 

Portable, self-contained laboratory 

Yes. 


Table 2 Comparison with CyberCIEGE. 


E. THE GAPS 

Based on its current design, CyberCIEGE matches most of the design 
requirements as proposed by [Tanner 2002]. However, there are certain areas that require 
further work. Specifically, these will serve as the requirements of the system that we 
shall develop in this thesis: 

1. Campaign Play 

CyberCIEGE improves upon the designs of CyberProtect and ISWS by 
supporting multiple scenarios as opposed to fairly static scenarios. This improvement 
can be taken a step further by providing a means for a student to progress from novice to 
sophisticated scenarios as suggested by [Tanner 2002]. This suggests a need for an 
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instructor tool for ordering a sequence of scenarios that progressively introduces new 
concepts and complexities to the student or to enable the assembly of a set of related 
scenarios built around a common theme. 

In order to support the concept of a campaign, there is a need to introduce further 
semantics to the current structure of the scenario definition file. The scenario definition 
file defines the goals of the organization and the resource options available to the student. 
This file is fed in as a input to the CyberCIEGE game to initialize the game and to setup 
the scenario environment that the student will play in. It would be particularly useful to 
introduce a taxonomy of classifications to each scenario so that instructors can easily 
assemble campaigns by stringing together relevant scenarios based on a subject focus, 
rather than having to scan through each scenario one at a time to determine the scope of 
each scenario. A tool can therefore be developed to support the definition of a taxonomy 
tree. The Scenario Builder, who is responsible for constructing these scenarios, would 
then associate the relevant taxonomy tags to each scenario. The latter requirement for 
taxonomy tagging will be undertaken by a separate thesis effort that involves the 
development of the Scenario Definition Tool. 

As CyberCIEGE currently plays scenarios independently, we have to provide the 
student with a tool to play through the scenarios of the campaign. This also suggests a 
need to define some means to interface with the CyberCIEGE game itself. 

2. After-Action Reviews 

Although not defined by [Tanner 2002], it is clear that a training package could be 
significantly enhanced if supported by some means to analyze student progress. This 
brings forth the idea of After-Action Reviews (AARs). As highlighted in [DOA 1993], 
AARs helps bridge the gap between concept and practice. Problem-solving skills can be 
improved through AARs. To achieve this, the instructor requires a tool to reconstruct 
significant elements of the game so that player progress and decisions can be reviewed. 

Through a temporal ordering of transpired events, we would wish to be able to 
answer these questions as suggested by [DOA 1993]: 

a. What happened? 


b. Why did it happen? 
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c. How can performance be improved? 

The tool can also help to provide useful metrics of the student’s progress, such as 
the amount of time taken, and to present snapshots of the player’s game state at 
significant stages for review. 

This scheme is only possible if there is a means to perform real-time interaction 
with CyberCIEGE to monitor events, or if event logging is performed. To achieve the 
objective of keeping CyberCIEGE “portable” and widely available, it is clearly not 
desirable to unnecessarily encumber it with real-time monitoring from an instructor 
station. Eurther, it would be undesirable for the instructor to monitor multiple game 
sessions (i.e. different students) in such a real-time manner. Hence, the latter approach of 
event logging for post-game analysis is a better fit for the purpose of AAR. In addition, 
this would further support the use of CyberCIEGE as a distance learning tool. The event 
log will permit asynchronous monitoring and student assessment. In order to achieve 
this, an event logging construct has to be built into the CyberCIEGE game itself. This 
thesis will therefore define the structure and organization of the event log. 

3. Support for Multiple Perspectives 

CyberCIEGE is currently designed to enable the player to participate only in the 
defender’s role. To enable the player to participate in attacker or forensic roles as 
suggested by [Tanner 2002] would require changes to CyberCIEGE itself and hence will 
not be explored within the scope of this thesis. Euther, [Irvine 2003] has also indicated 
that this is planned for a future iteration of CyberCIEGE’s development. 
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III. ANALYSIS 


A. CONCEPT OF OPERATIONS 

We shall next deseribe the broad eoncept of operations for the tools to be 
developed (see III.B for deseriptions of the respeetive actors): 

The Taxonomy Manager will manage a taxonomy of lA terms. When seenarios 
are ereated, this taxonomy of terms are used by the Seenario Builder to catalog the 
scenarios. This will facilitate convenient downstream retrieval when we need to select 
scenarios for inclusion into a campaign. The taxonomy tagging of scenarios will not be 
encompassed within the scope of this thesis. 

The Instructor can then proceed to create campaigns, where each campaign is 
made up of a sequence of previously developed scenarios. Once a campaign definition is 
completed, it can be released and is ready for use by the Student. 

The Student will proceed to launch CyberCIEGE to play each of the scenarios. 
During game play, CyberCIEGE will generate events which are recorded into event logs. 
The resultant event logs are then used for analysis by the Instructor. 

B. ACTORS 

An actor, as defined in [Eeffingwell 1999], is “someone or something, outside the 
system, that interacts with the system”. This includes users who have a role to play and 
external systems that are interfaced with. Eive such actors are defined. Of these, the 
Taxonomy Manager, Instructor and Student are users who perform a role, while 
CyberCIEGE and the Scenario Definition Tool are external systems (see Eigure 8). 
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1. Taxonomy Manager 

The Taxonomy Manager is a user responsible for managing the taxonomy library 
of terms. 

2. Instructor 

The Instructor is a user responsible for constructing campaigns with a teaching 
objective in mind and for conducting the AAR with the Student. 

3. Student 

The Student is responsible for playing through the ordered set of scenarios of a 
campaign to learn and apply information assurance concepts. 

4. CyberCIEGE 

CyberCIEGE is the game itself and is treated as an external system. 

5. Scenario Definition Tool 

The Scenario Definition Tool is an external system used to construct scenario 
definitions. 

C. USE CASES 

The Use Case modeling approach of the Unified Process, as described by 
[Jacobson 1999] and [Eeffingwell 1999] is adopted for the development effort. 



Eigure 9. Use case model survey. 
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The detailed use case specifications are provided in Appendix A. Here we shall 
briefly summarize and explain the purpose of the use cases defined. 

1. [UC.l] Manage Taxonomy 

In this use case, The Taxonomy Manager defines and manages the taxonomy of 
security terms. The terms are created in a hierarchical order and presented as a tree 
structure. 

This is desired in order to establish a common vocabulary for the taxonomy of 
terms which are used subsequently by people designing scenarios using the Scenario 
Definition Tool for purposes of cataloging the scenarios, and again in the Campaign 
Manager to search and retrieve scenarios. 

2. [UC.2] Setup Campaign 

In this use case, the Instructor either selects an existing campaign or creates a new 
campaign to work with. The Instructor can then name and describe the objectives of the 
campaign, and select pre-created scenarios for inclusion in the campaign. A filter can be 
defined to select specific taxonomy terms, thereby narrowing the set of selectable 
scenarios to those tagged with the relevant taxonomy terms. 

Essentially, this use case has the responsibility for creating and editing the 
campaign definition. 

3. [UC.3] Release Campaign 

Once the campaign has been fully defined, this use case supports its release for 

play. 

In this use case, a campaign which is ready for release undergoes an integrity 
check to finalize the campaign package. This ensures that the referenced Scenario 
Definition Files are physically present. The campaign is then base-lined and the 
Campaign Definition File (campaign.xml) and the respective Scenario Definition Files 
(*.sdf) are copied into a directory defined by the Instructor. The campaign is now ready 
for the Student to play and is no longer editable. 

4. [UC.4] Conduct After-Action Review (AAR) 

Once the scenario is started in CyberCIEGE, event logs will begin to be 
generated. The Instructor can then begin to perform AAR activities. It is not necessary 
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to wait till the scenario has been fully played out to do so. 

In this use case, the Instructor selects a campaign to be reviewed by loading the 
Campaign Definition File. Summary information of all students involved are retrieved 
from their respective event log files and is displayed. The Instructor is therefore 
presented with a quick overview of the current status of all his students. The Instructor 
may find a need to examine further details of a particular Student and can do so by 
selecting and calling up the event log pertaining to that Student. The Instructor can then 
analyze the event logs in detail. Where a snapshot of the game “state” has been saved, 
the Instructor can call it up for analysis and discussion with the Student involved. As the 
snapshot is implemented as a saved game in CyberCIEGE, we only need to launch 
CyberCIEGE with the saved game reloaded to restore the game “state”. 

5. [UC.5] Load Campaign 

With the campaign released, each Student can proceed to play the selected 
scenarios of the campaign. 

In this use case, the Student loads the campaign in order to review the objectives 
of the campaign, and the scenarios to be played. 

6. [UC.6] Play Scenario 

In this use case, the Student proceeds to play a scenario from the campaign. 
CyberCIEGE is automatically launched with the scenario loaded at its start state. 

The Student will play out the scenario in CyberCIEGE. As the game progresses, 
CyberCIEGE will automatically log events taking place. 

D. INTERFACES WITH CYBERCIEGE (RIVERMIND) 

The CyberCIEGE game engine itself is being developed by Rivermind Inc. 
Interfaces have to be clearly defined to facilitate parallel work. The detailed interface 
specifications with Rivermind are presented in Appendix C. These include specific 
requirements for the Scenario Definition Eile format, the CyberCIEGE command line 
parameter specification and the Event Eog Eile format. 

I. Scenario Definition File Format 

When this thesis effort first began, the Scenario Definition Eile had been partially 
defined and was still a work-in-progress. It was felt that in order to facilitate the 
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campaign construction; scenarios would need to be given a title. Similarly, in order to 
have meaningful AAR, the need for game termination conditions were also raised - i.e. to 
stop the CyberCIEGE game when a win or loss condition is met. Consequently, these 
were introduced into the Scenario Definition Eile format. 

2. Command-line Parameters 

We also need to be able to launch CyberCIEGE under two (subsequently three) 
situations. Eirstly, the Student needs to launch a specific scenario with event logging 
turned on, in order to play the game. Secondly, the Instructor may also want to do the 
same in order to examine the start state of a scenario. In this case however, the event 
logging would not be turned on. A command-line syntax was thus defined to allow these 
variations: 

> CyberCIEGE -s <Scenario Eile> [-i <IDTag> -e <EventEog>] 

Einally, it was decided that to support the capability to save game states at defined 
points of a game, this would be implemented by simply having CyberCIEGE to perform 
a save game function. These defined points would be scripted into the scenario definition 
as conditions and event triggers. During campaign analysis, we would use the Campaign 
Analyzer to call up CyberCIEGE with the saved game reloaded. Hence, an additional 
command-line option was introduced to do this: 

> CyberCIEGE -1 <Saved Eile> 

3. Event Logging 

Event logging is needed so that we would be able to use the logs to review game 
progress. The question is, under what circumstance should a log be recorded and how 
should these be defined? Eixed event loggings would require that all logging points be 
coded into CyberCIEGE itself. This is clearly inflexible. A scriptable form of logging is 
preferred so that the Scenario Builder has some latitude in defining under what conditions 
to trigger a log record, and to specify what should be logged. The syntax and semantics 
to support this has been included in the Scenario Definition Eile format. 

The Event Eog Eile format was correspondingly defined, and the specification is 
detailed in Appendix C. The file format is based on XME [W3C 2003] which is an 
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industry-wide open standard. Figure 8 illustrates a sample fragment of the Event Log 
File: 


<summaryevent> 

<dtimereal>20030818193015</dtimereal> 
<dtimegame>20030131062359</dtimegame> 

<daily> 

<budget> 10000</budget> 

<sales>0</sales> 

<salaries>5000</salaries> 

<hardw areexp>0</hardw areexp> 
<softwareexp>0</softwareexp> 

<misc>0</misc> 

<cash>5000</cash> 

</daily> 

</summaryevent> 

<controlevent> 

<dtimereal>20030818203015</dtimereal> 
<dtimegame>20030131070100</dtimegame> 
<savetrigger> 

<tagdata># 1 </tagdata> 

<filename> l_scenario 1_0001 .sav</filename> 
</savetrigger> 

</controlevent> 

<userevent> 

<dtimereal>20030818193015</dtimereal> 
<dtimegame>20030131062359</dtimegame> 

<hire> 

<name>Mr. Gates</name> 

<salary>5000</s alary> 

</hire> 

</userevent> 

<componentevent> 

<dtimereal>20030818193015</dtimereal> 
<dtimegame>20030131062359</dtimegame> 

<buy> 

<catalogname>SuperX 9000 Server</catalogname> 

<componentname>dbserver#l</componentname> 

<cost>3000</cost> 

</buy> 

</componentevent> 

Figure 10. Sample fragment of an Event Log File. 
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E. INTERFACES WITH SCENARIO EDITOR 


The Scenario Editor is being developed by Ken Johns in his thesis. As the 
Scenario Editor would need to perform the Taxonomy-tagging required by the Campaign 
Manager module, coordination was required. 

1. Taxonomy File Format 

The specification of the Taxonomy File format is detailed in Appendix D. The 
Taxonomy File adopts the XME format to organize the taxonomy terms in a hierarchical 
order. Shown here is a sample fragment of the Taxonomy File: 

<simsecuritytaxonomy> 

<tnode> 

<tname>Encryption</tname> 

<tnode> 

<tname>Public Key Encryption</tname> 

<tnode> 

<tname>RSA</tname> 

</tnode> 

</tnode> 

<tnode> 

<tname>Symmetric Key Encryption</tname> 

</tnode> 

</tnode> 

<tnode> 

<tname>E-voting</tname> 

</tnode> 

</simsecuritytaxonomy> 

Figure 11. Sample fragment of a Taxonomy File. 

2. Embedded Taxonomy Tags in the Scenario Definition File 

Because the taxonomy tagging is not an integral part of a scenario definition, it 
was decided that these internal tagging would not be specified as part of the standard 
Scenario Definition File format. Instead, we take advantage of the embedded comments 
construct of the scenario definition file to provide the needed extensibility. The symbol 
just as in C-t-i- and Java, is used in the Scenario Definition File to denote that all 
character strings following it up to the end-of-line are part of a comment and are ignored 
during scenario parsing. 

Hence, the taxonomy tags construct would appear with the comments prefix as 
shown in the following example in the Scenario Definition File, bounded by the 
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“TaxonomyTag:” and “:end” pair. The text in between would correspond to <tnode>s 
shown in Figure 11. 

// TaxonomyTag: Public Key Encryption :end 
// TaxonomyTag: E-voting :end 

Eigure 12. Taxonomy tag embedded in a Scenario Definition Eile. 
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IV. DESIGN & IMPLEMENTATION 


A. DESIGN 

In general, the approach taken was to define a Design Use Case for each Analysis 
Use Case; hence there is a one-to-one mapping from analysis to design. 



Figure 13. Transitioning from analysis to design. 


As described in [Bruegge 2000], an analysis object model consists of entity, 
boundary and control objects. These stereotypes are defined as such: 

• Entity - An entity object represents persistent information tracked by the 
system. 

• Boundary - A boundary object represents the interactions between actors 
and the system. 

• Control - A control object represents the tasks that are performed by the 
user and supported by the system. 

In addition, a Builder object stereotype is introduced. It is an object to interact 
with a persistent store to perform load and save operations. 

This structure for organizing analysis object models was carried over into the 
design model. Thus, the architectural look-and-feel for each Design Use Case is typically 
as shown in Figure 14: 



Figure 14. Design model template. 
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A Control object is defined for each use case. This object handles all the 
coordination between Graphical User Interface (GUI) objects and entity objects. 

GUI objects are created for each user interface that interacts with the actor. 
Typically, each use case has a main GUI form, supported by some secondary GUIs. GUI 
objects handle all user interactions, but any processing tasks would be passed onto the 
Control object to perform. 

In sharp contrast. Entity objects are typically passive. These are created for each 
object whose principle responsibility it is to hold information. In addition. Builder 
objects were also created to handle the reading and writing of entity objects to the file 
system as XML files. 

The respective Design Use Cases are extensively described in Appendix B, 
illustrated with Collaboration Diagrams. 

B. IMPLEMENTATION 

The following table maps the realization of the respective use cases to four 
software modules developed in this thesis. 


Application 

Modules 

Analysis/Design Use Cases 

TaxonomyManager 

[UC.l] Manage Taxonomy 

CampaignManager 

[UC.2] Setup Campaign, [UC.3] Release Campaign 

CampaignPlayer 

[UC.5] Load Campaign, [UC.6] Play Campaign 

CampaignAnalyzer 

[UC.4] Conduct AAR 


Table 3 Use case realization. 


All the software modules are implemented using the Java 2 SDK vl.4.1 [Sun 

2003]. 

Structurally, the implementation modules are organized into two layers as 
illustrated in the figure below. The respective application modules (packages) are 
dependent on the Utilities package. Brief descriptions of the respective code units are 
provided in Appendix E. 
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Taxonomy Manager Campaign Manager Campaign Player Campaign Anaiyzer 



Figure 15. Layered architecture. 

The inter-relationship between the modules and the various data files is illustrated 
in the next block diagram. As shown, the darker rectangle represents the boundary that is 
within the scope of this thesis. 



Figure 16. Inter-relationships between the modules and files. 

The Taxonomy Manager is responsible for managing the taxonomy terms stored 
in the Taxonomy File. The later is then used by the Scenario Editor to select Taxonomy 
terms to be tagged to the Scenario Definition Files that it is creating. 
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The Campaign Manager processes the respective Scenario Definition Files to 
obtain a list of scenarios. Specific scenarios are then selected for inclusion into the 
campaign. Subsequently, the Campaign Manager creates the Campaign Definition File. 

The Campaign Player loads the Campaign Definition File and selects a scenario to 
play. This results in CyberCIEGE being launched using the Scenario Definition Eile (not 
shown in figure). Event Eog Eiles are generated by CyberCIEGE. 

Einally, the Campaign Analyzer loads a Campaign Definition Eile and parses the 
related Scenario Definition Eiles. Selectively, Event Eog Eiles may be selected to be 
viewed as well. 

C. INTEGRATION 

One of the key limitations of this effort is that the CyberCIEGE development is 
not due for completion till early 2004 while this thesis was to be completed by Dec 2003. 
In addition, the parallel thesis effort by Ken Johns to develop the Scenario Definition 
Tool is also not due for completion until Mar 2003. 

Due to this mismatch of schedules, stubs were used in lieu of integration testing 
of the interfaces with CyberCIEGE. Similarly, taxonomy-tagged Scenario Definition 
Eiles and the Event Eog Eiles were artificially hand-created to simulate these artifacts. 
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V. DISCUSSION 


A. RESULTS 

1. Application Modules 

The four application modules have been developed. Shown here are screenshots 
from the respective modules. This section also serves as a user guide. 
a. Taxonomy Manager 

In the Taxonomy Manager screen below (Figure 17), we can see the 
hierarchical structure of the taxonomy terms. The Taxonomy Manager (actor) can add, 
edit or delete the respective terms. Deleting a parent node will cause all the sub-nodes to 
be deleted as well. 



Figure 17. Taxonomy Manager. 
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Once all the desired changes have been made, the changes can be saved 
into the persistent store - i.e. as an XML file called “Taxonomy.xml”. 
b. Campaign Manager 

In the main screen of the Campaign Manager module (Figure 18), the 
Instructor can review the existing campaigns which have been defined. New campaigns 
can be created from here, while existing campaigns can be edited or deleted. 



Figure 18. Campaign Manager. 

Creating a new campaign or editing an existing one will bring up the 
Campaign screen as shown in Figure 19. 
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Figure 19. Campaign Manager - constructing the campaign. 

Here, the Instructor can modify the name and description of the campaign, 
as well as to select and organize the scenarios. Additional scenarios can be added while 
existing selections can be dropped. The Instructor can move scenarios up or down, 
organizing them in the sequence desired. 

To narrow the scenarios selectable, the Instructor can call up the filter to 
define the desired taxonomy. This is especially useful if the campaign is being created 
around a specific theme. By choosing the relevant taxonomy terms that pertain to this 
theme, the list of selectable scenarios is reduced to just those scenarios that exhibit one or 
more of the taxonomy terms selected. 
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Figure 20. Campaign Manager - taxonomy-based scenario filter. 

In the filter screen shown in Figure 20 for instance, if the taxonomy term 
“Public Key Encryption” is selected, then any scenario which has been tagged with either 
“Public Key Encryption” or “RSA” would be selectable. 

Clearing the filter implies that no taxonomy filtering is to be applied. 
Therefore, all scenarios would be selectable. 

c. Campaign Player 

The Student will be primarily using this module to launch scenarios to 
play. Selecting a campaign will bring up the campaign details as defined by the 
Instructor. Scrolling through each of the scenarios, the Student can review the 
description (i.e. briefing notes) of the selected scenario. 
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Figure 21. Campaign Player. 

Once the Student is ready, he/she can play that scenario. This will cause 
the CyberCIEGE game to be launched with that scenario. 

d. Campaign Analyzer 

The Instructor uses the Campaign Analyzer to view the progress of the 
Students. By selecting a campaign, the Campaign Analyzer will call up all the details of 
the campaign. The module also automatically checks for the status of each Student and 
summarizes their current status on the display as shown at the bottom of the next screen. 
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Figure 22. Campaign Analyzer. 

The status summary can provide an indication of the Student’s status to 
the Instructor. The status column indicates whether the Student has started (“Started”, 
“Not started”) or completed (“Won”, “Lost”) the scenario. Other information include the 
Student’s current budget status, the time that the scenario was started and ended, and the 
total number of days elapsed in terms of real gaming time. At a glance, the Instructor 
will be able to identify Students who may be way behind schedule on that scenario - e.g. 
not started yet, or started but has yet to complete. Or the Instructor may notice that a 
particular Student is taking a lot more time to play than the rest. This may warrant 
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further investigation of that particular Student’s progress. To accomplish this, the 
Instructor can choose to view that Student’s logs to find out the cause. 

Choosing “View Log” will bring up the Event Log Analyzer (Figure 23). 
Here, the Instructor can systematically browse through each of the events logged for that 
Student’s game. 



Figure 23. Event Log Analyzer. 
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For the scope of this thesis, only a partial set of events are processed and 
presented. These are shown in Table 4: 


EventType 

Event Sub- 

Type 

Properties 

controlevent 

debuglog 

tagdata, message 

logtrigger 

tagdata, message 

popuptrigger 

tagdata, message 

tickertrigger 

tagdata, message 

savetrigger 

tagdata, filename 

gameevent 

start 


end 

“win” or “lose” 

pause 


resume 


save 


exit 


quit 


summaryevent 

daily 

budget, status, salaries, hardwareexp, softwareexp, misc, cash 

monthly 

budget, status, salaries, hardwareexp, softwareexp, misc, cash 

userevent 

hire 

name, salary 

fire 

name, salary 

componentevent 

buy 

catalogname, componentname, cost 

sell 

catalogname, componentname, cost 

configure 


alertevent 

indicator 

securitytarget, targetname, message 

attack 

securitytarget, targetname, attacktype, result 


Tabled Implemented set of events. 

Where a game saved state has been recorded, the Instructor can review 
that saved state. Effectively, this will bring up the CyberCIEGE game, loading the saved 
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game file. The Instructor can then examine the state of the Student’s game within 
CyberCIEGE itself to gain insights. 

2. Interface Specifications 

Interface specifications are essential to ensure that different developers are able to 
work in parallel loosely-coupled, whilst developing modules that can be tightly- 
integrated. 

Various interface specifications were defined in the course of this thesis research. 
These are described in more details in Appendices B and C. This has enabled the 
respective parties (i.e. Rivermind and Ken Johns) to proceed with their development 
efforts in parallel. Their respective efforts are not due for completion until much later 
downstream. 

3. Influences on the Design of CyberCIEGE 

During the early and mid stages of this thesis research, NFS and Rivermind were 
engaged in active discussions defining the Scenario Definition Eormat. In these early 
stages, the focus of the discussions was generally centered on what the Scenario Builder 
needed in order to present CyberCIEGE with the desired scenario. This involved 
numerous meeting iterations defining the various elements of the game; such as the 
components, and the security and configuration attributes. 

As this thesis effort was focused on developing tool support for the Instructor, it 
helped to bring a new perspective to these discussions. In particular, we had to examine 
how an Instructor interacts with CyberCIEGE in various ways. Eor instance, to effect 
some form of “control” of the CyberCIEGE game itself, command-line parameter 
constructs were defined to launch the CyberCIEGE game to do different things. 
Conditions and triggers had to be defined within the Scenario Definition Eile itself to 
enable the Scenario Builder to influence the game as it progresses. And finally, to extract 
meaningful data from a game in progress which can be used to analyze the Student’s 
progress. These helped to ensure the completeness of the Scenario Definition Eormat 
specification effort and serves as a form of validation check of CyberCIEGE’s design. 

In particular, we note that in addition to presenting the scenario to the game 
engine, the scenario definition also has to provide scripted control of the game so that an 
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Instructor is able to conduct post-game analysis (or after-action reviews). 

In the same light, there are also various thesis research initiatives being 
undertaken, involving the development of educational scenarios. To facilitate their 
research efforts, it would be necessary for the CyberCIEGE game to be able to produce 
results which can be analyzed. The event logging mechanism would be a useful means to 
support this. 

B. THE QUESTIONS ANSWERED 

This thesis was initiated to examine three key questions. We shall now discuss 

these. 

The first question was, “How do we construct and organize scenarios to provide 
an educational focus on an lA-specific topic?” What we have done has been to 
demonstrate the viability of layering the notion of a campaign on top of the scenario to 
achieve this. By organizing a set of scenarios into a campaign and having the student 
play through the scenarios, we enable the student to step through progressive scenarios, 
learning concepts one step at a time. 

In order to facilitate campaign construction, we have further identified that it is 
beneficial to support a notion of taxonomy-tagging of scenarios. As this function is 
optimally best performed by the Scenario Builder, this has also resulted in additional 
requirements for the Scenario Editor. 

The second question was, “What do we need in order to perform student 
assessment of the scenarios played?” As has been extensively discussed, this involved 
the introduction of conditions and triggers into the scenario design, and to have the 
CyberCIEGE game to perform event logging. Parsing the event logs, we can then present 
the necessary information to the Instructor to perform analysis. 

Einally, the last question was, “What interfaces must be introduced into 
CyberCIEGE to achieve this?” This is answered through the interface specifications 
defined in Appendix C. 
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VI. CONCLUSION 


A. CONCLUSION 

With the concept and the tools developed from this thesis research, it is now 
possible to make the CyberCIEGE game into a more complete instructional package. By 
layering the idea of a campaign on top of the scenarios, we have provided a way for 
organizing progressive and/or focused training packages. The tools provides for the 
construction and support for measurable assessment of student performance of the given 
scenarios to assess learning progress. 

It has also served to enable the Scenario Definition Eile format to be more 
comprehensively defined, thereby enabling the necessary control and interaction with the 
CyberCIEGE game to support educational objectives. 

As a more complete package, the CyberCIEGE effort is a step closer towards 
serving as an educational tool to promote greater cyber-defense awareness and 
understanding. 

B. FURTHER WORK 

As an initial effort in this area, there is certainly a lot more room for 
improvement. The following are some suggested areas for further research. 

1. Improved Details & Usability 

The graphical interfaces of the tools could be further improved to provide more 
information and improved usability. Presently, to demonstrate its viability, only critical 
elements are presented in the user interfaces. There may be more information that the 
Instructor would find useful when constructing the campaigns. Eor example, it would be 
useful during campaign creation if the Instructor were able to call up the Scenario 
Definition Tool to examine the details of a specific scenario, to obtain a better 
understanding of the scenario and to make selection decisions. In the scenario selection 
screen (Eigure 19), it may be better to display the filter together with the list of scenarios. 

2. Taxonomy of Terms 

It may be worth examining how best to define a taxonomy of terms so that its 
usefulness to the Instructor is maximized to support scenario selection. 
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Presently, the structure of the taxonomy of terms allows the Taxonomy Manager 
to define the same term under more than one sub-tree. When the Instructor is 
constructing a campaign, the filter will enable selection of scenarios which have that 
taxonomy term defined, regardless of the sub-tree from which that term was actually 
selected. An improvement to this would be to fully qualify the taxonomy term. For 
example, “Cryptography” defined as “Confidentiality: Cryptography” would be 
differentiated from “Authentication:Cryptography”. 

3. Event Log Analysis 

The present tool for event log analysis only displays the logged events in a tabular 
format for the Instructor to review. More improvements could be made in this area to 
provide a graphically-based time-line display of the events and other analysis tools. 

The current implementation has only incorporated a subset of the events being 
logged. The event log format is also likely to be expanded in the future, incorporating 
more event types. Consequently, the implementation would also need to be enhanced to 
provide commensurate support. 
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APPENDIX A. USE CASE SPECIFICATIONS 


A. PURPOSE 

This appendix documents the Analysis Use Case Specification, describing each 
Use Case in detail. 

B. USE CASES 

1. [UC.l] Manage Taxonomy 
Brief Description: 

The Taxonomy Manager defines and manages a taxonomy of security 

terms. 

Primary Actor(s): 

Taxonomy Manager. 

Secondary Actor(s): 

Nil. 

Flow of Events 

Basic Flow 

1. The use case begins with the Taxonomy Manager loading the 
taxonomy of security terms. The taxonomy is expressed as a hierarchy of security terms 
(Figure 24). The Taxonomy Manager can then proceed to update the hierarchy by 
performing any of steps 2 to 4 iteratively. 

2. The Taxonomy Manager can add a new term to the hierarchy. 

3. The Taxonomy Manager can select an existing term and delete it. 
This will also delete any terms which are sub-nodes of the hierarchy. 

4. The Taxonomy Manager can edit an existing term by renaming it. 

5. At any point after completing any of steps 2 to 4, the Taxonomy 
Manager can save the updated hierarchy. 

6. Alternatively, the Taxonomy Manager could discard all the 
changes made and revert to the last saved version. 
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7. When the Taxonomy Manager is done, he can close the taxonomy 
editor and end the taxonomy editing. However, if there has been a change since the last 


save, the Taxonomy Manager is prompted to save or discard the changes. 
8. The use case then ends. 



Figure 24. Taxonomy Editor. 

Alternate Flows 

Nil. 

Special Requirements 
Nil. 

Pre-conditions 

Nil. 

Post-conditions 

Nil. 

2. [UC.2] Setup Campaign 

Brief Description: 

The Instructor sets up a campaign by describing the objectives of the 
campaign and by composing a collection of related scenarios. 

Primary Actor(s): 


46 

















Instructor. 

Secondary Actor(s): 

Nil. 

Flow of Events 

Basic Flow 

1. The use case begins with the Instructor calling up the Campaign 
Manager and selecting a campaign to work on or create a new one if desired. 



Figure 25. Campaign Manager. 

2. When creating a new campaign, the Instructor will assign a name 
and a description to the campaign. The Instructor can also rename or modify the 
description of an existing campaign. 

3. With the campaign defined, the Instructor can proceed to select 
scenarios to be added into it. He can do this by selecting a scenario from the available 
list of scenarios. 

4. Scenario selection can be accelerated by filtering the scenarios 
based on taxonomy tags. 

5. Once a scenario has been added to the campaign, the scenario 
sequence can be rearranged. 

6. The Instructor can then save or discard the campaign. 
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7. 


The Instructor can also delete a campaign. 



Figure 26. Campaign editor. 

Alternate Flows 

Nil. 

Special Requirements 
Nil. 

Pre-conditions 

Nil. 

Post-conditions 

Nil. 

3. [UC.3] Release Campaign 

Brief Description: 

A campaign which is ready for release undergoes an integrity check to 
finalize the campaign package. The campaign is then base-lined and ready for the 
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Student to play. 

Primary Actor(s): 

Instructor. 

Secondary Actor(s): 

Nil. 

Flow of Events 

Basic Flow 

1. The use case begins with the Instructor selecting a campaign. 



Figure 27 


Releasing a campaign. 


2. The Instructor can then “release” it for Students to play it. This 
will result in an integrity check to ensure that all the scenarios of the campaign are 
consistent - i.e. the corresponding scenario definition files are physically present. 

3. Once the checks are successful, the campaign can be accessed by 
the Student for playing. 
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4. If there are any errors, the Instructor is informed of the sources of 
errors. The Instructor updates the campaign definition as necessary to fix the problem. 
For instance, the scenario file itself may be missing and hence need to be removed. 

5. The use case ends when the Instructor completes the release of the 
campaign, or abandons the attempt to release the campaign. 

Alternate Flows 

Nil. 

Special Requirements 
Nil. 

Pre-conditions 

Nil. 

Post-conditions 

Campaign is now released for Student to play. 

4. [UC.4] Conduct After-Action Review 

Brief Description: 

The Instructor conducts an after-action review of the Students’ 
performance by analyzing the event logs. 

Primary Actor(s): 

Instructor. 

Secondary Actor(s): 

Student, CyberCIEGE, Scenario Definition Tool. 

Flow of Events 

Basic Elow 

1. The use case begins when the Instructor selects a campaign to be 
analyzed. This may be conducted together with the Student. 

2. The campaign details are loaded, including the scenarios defined 
for the campaign. The first scenario is selected by default. 

3. When a scenario is selected, the display will show each Student’s 

status. 
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Figure 28. Campaign Analyzer. 

4. If the Instructor so chooses, he/she can select to view a Student’s 
event logs to analyze further. 

5. The event log is then loaded, and its details displayed (Figure 29). 
This displays the events sorted by default in real date/time order. 

6. As an event is selected, the corresponding details (i.e. event 
property and value) for that event are displayed. 
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7. If the event is a saved game state, the Instructor can load the saved 
state for further analysis. This will actually load CyberCIEGE with the associated saved 
game file. 



Figure 29. Event Eog Analyzer. 

8. The Instructor can apply filter conditions to filter the events being 
displayed. Filter options include selection of a date/time window in terms of the real¬ 
time and/or game-time, and by event types. 
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9. The Instructor can clear any existing filter options and redefine a 

new one. 

10. Once all the filter options have been set, the Instructor can apply 
the filter. This will filter those events that meet the filter options to be displayed on the 
events table. 

11. The use case ends when the Instructor is done analyzing the 
campaign and related scenarios. 

Alternate Flows 

Nil. 

Special Requirements 
Nil. 

Pre-conditions 

Nil. 

Post-conditions 

Nil. 

5. [UC.5] Load Campaign 

Brief Description: 

The Student loads the campaign to review the objectives of the campaign, 
and the scenarios to be played. 

Primary Actor(s): 

Student. 

Secondary Actor(s): 

Nil. 

Flow of Events 

Basic Flow 

1. The use case begins with the Student calling up the Campaign 
Player module (Figure 30). The Student’s identity is automatically determined from the 
operating system. 

2. The Student then selects a campaign definition file. 
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3. This loads the campaign and its details such as the campaign name 
and campaign description. The sequence of scenario names involved is also displayed. 

4. The Student can repeatedly review each scenario by selecting the 

scenario. 


5. As a scenario is selected, the scenario name and its description are 

displayed. 



Figure 30. Campaign Player. 


54 






















6. The use case ends when the Student has finished reviewing the 
campaign and the scenario descriptions. 

Alternate Flows 

Nil. 

Special Requirements 
Nil. 

Pre-conditions 

Nil. 

Post-conditions 

Nil. 

6. [UC.6] Play Scenario 

Brief Description: 

The Student proceeds to play a scenario of the campaign. 

Primary Actor(s): 

Student. 

Secondary Actor(s): 

CyberCIEGE. 

Flow of Events 

Basic Elow 

1. The use case begins with the Student having selected a scenario of 

the campaign. 

2. The Student can decide to play the currently selected scenario. 

3 This will result in CyberCIEGE being launched to play that 

scenario. 
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Figure 31. Playing a scenario. 

Alternate Flows 

Nil. 

Special Requirements 
Nil. 

Pre-conditions 

UC.5 must have been performed prior, to load a campaign to work on. 
Post-conditions 
Nil. 
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APPENDIX B. DETAILED DESIGN 


A. PURPOSE 

The purpose of this appendix is to document the detailed design of the application 
modules. These are described using Design Use Cases, supported by collaboration 
diagrams. 

B. DYNAMIC VIEW - USE CASE DESIGN 

For the description of the design use cases, the convention adopted is to use bold 
font for classes/objects and the method calls. Methods are suffixed with parenthesis but 
parameters are not presented. GUI interactions are typically not described in details, 
except for key interactions that significantly affect the use case. 

I. [UC.I] Manage Taxonomy 
Brief Description: 

The Taxonomy Manager (actor) defines and manages the taxonomy of 

security terms. 

Primary Actor(s): 

Taxonomy Manager. 

Secondary Actor(s): 

Nil. 

Flow of Events 

Basic Flow 

1. The use case begins with TaxonomyManager creating a new() 
instance of TaxonomyCtl. 

2. TaxonomyCtl in turn creates a new() instance of 
TaxonomyBuilder. TaxonomyBuilder is responsible for loading the Taxonomy 
hierarchy. 

3. TaxonomyCtl then retrieves the root Taxonomy object by doing 

getTaxonomyRootO from TaxonomyBuilder. 
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Figure 32. [UCl.O] Basic Flow: Manage Taxonomy. 

4. TaxonomyCtl then creates a new() instance of the 

Taxonomy GUI. 


5. Taxonomy Manager then calls TaxonomyCtl to showGUI(). 

6. And TaxonomyCtl in turn calls TaxonomyGUI to showForm(). 

7. From here, the Instructor can interact with the TaxonomyGUI to 
[UCI.I] Add Taxonomy, [UCI.2] Edit Taxonomy, [UCI.3] Delete Taxonomy or 
[UC1.4] Save Taxonomy. The use case ends when the Taxonomy Manager (actor) 
performs [UC1.5] Cancel/Close Taxonomy Session. 

rUCl.l1 Scenario: Add Taxonomy 



Figure 33. [UCl.l] Scenario: Add Taxonomy. 

1. In this scenario, the Taxonomy Manager selects the Add button 
which triggers onButtonAdd() of TaxonomyGUI. TaxonomyGUI will ask the 
Instructor to key in the taxonomy term. 


58 







2. Once the Taxonomy Manager is done with the entry, 
TaxonomyGUI then calls onAdd() of TaxonomyCtl. If the Taxonomy Manager cancels 
the addition request, the creation is abandoned and the scenario ends. 

3. TaxonomyCtl will then create a new() Taxonomy object, and the 

scenario ends. 

rUCl.21 Scenario: Edit Taxonomy 



Figure 34. [UC1.2] Scenario: Edit Taxonomy. 

1. In this scenario, the Taxonomy Manager selects the Edit button 
which triggers onButtonEdit() of TaxonomyGUI. TaxonomyGUI will display the 
current taxonomy value and ask the Taxonomy Manager to edit it. 

2. Once the Taxonomy Manager is done, TaxonomyGUI then calls 
onEditO of TaxonomyCtl. If the Taxonomy Manager cancelled the edit, the editing is 
abandoned and the scenario ends. 


3. TaxonomyCtl will then rename() the Taxonomy object, and the 

scenario ends. 

rUCl.31 Scenario: Delete Taxonomy 



Eigure 35. [UC1.3] Scenario: Delete Taxonomy. 
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1. In this scenario, the Taxonomy Manager selects the Delete button 
which triggers onButtonDelete() of Taxonomy GUI. TaxonomyGUI will ask the 
Instructor to confirm the deletion request. 

2. If the Taxonomy Manager confirms the deletion request, 
TaxonomyGUI then calls onDelete() of TaxonomyCtl, else the deletion request is 
abandoned and the scenario ends. 

3. TaxonomyCtl will then call parent() of the Taxonomy object to 
retrieve the parent Taxonomy object. 

4. Using the parent Taxonomy object, TaxonomyCtl then calls it to 
removeChildO, and the scenario ends. 

rUCl.41 Scenario: Save Taxonomy 



Figure 36. [UC1.4] Scenario: Save Taxonomy. 

1. In this scenario, the Taxonomy Manager selects the Save button 
which triggers onButtonSave() of TaxonomyGUI. 


2. TaxonomyGUI then calls onSave() of TaxonomyCtl. 

3. TaxonomyCtl will then call the TaxonomyBuilder to save(), and 
the scenario ends. 

rUCl.51 Scenario: Cancel/Close Taxonomy Session 



Figure 37. [UC1.5] Scenario: Cancel Taxonomy Session. 
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1 . 


In this scenario, the Taxonomy Manager selects the Cancel button 
which triggers onButtonCancel() of Taxonomy GUI. 

2. Taxonomy GUI will check with Taxonomy Ctl if it has been 

modified(). 

3. If it has been modified, the Taxonomy Manager will be asked if 
the changes should be saved, ignored or to cancel this Cancel selection. If it is cancelled, 
then the scenario ends. If it is to be saved, then TaxonomyCtl is called to do onSave(). 

4. In which case, TaxonomyCtl will in turn call TaxonomyBuilder 

to save(). 

5. The application then shuts down, and the scenario ends. 

Special Requirements 

Nil. 

Pre-conditions 

Nil. 

Post-conditions 

Nil. 

2. [UC.2] Setup Campaign 

Brief Description: 

The Instructor sets up a campaign by describing the objectives of the 
campaign and by composing a collection of related scenarios. 

Primary Actor(s): 

Instructor. 

Secondary Actor(s): 

Nil. 

Flow of Events 

Basic Flow 

1. The use case begins with the CampaignManager creating a new() 
instance of CampaignManagerCtl. 

2. CampaignManagerCtl in turn creates a new() instance of the 

ScenarioCatalogBuilder. 
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3. And calls ScenarioCatalogBuilder to load() the catalog of 

scenarios. 


4. Finally, it calls getScenarios() from ScenarioCatalogBuilder. 

5. CampaignManagerCtl next creates a new() instance of 

CampaignCatalogBuilder. 



Figure 38. [UC2.0] Basic Flow: Setup Campaign. 

6. And calls CampaignCatalogBuilder to load() the catalog of 

campaigns. 


7. Finally, it calls getCampaigns() from CampaignCatalogBuilder. 

8. Next, for each Campaign retrieved, CampaignManagerCtl 

informs the CampaignManagerGUI to addCampaign() into the GUI. 

9. Finally, it informs CampaignManagerGUI to selectDefaults(). 

10. CampaignManager then calls CampaignManagerCtl to 

showGUIO. 

11. Which, in turn, performs a similar function with 

CampaignManagerGUI by calling showForm(). 

12. The Instructor can then proceed to interact with the 

CampaignManagerGUI using [UC2.1] New Campaign, [UC2.2] Edit Campaign, [UC2.3] 
Delete Campaign or [UC2.4] Save Campaigns. The use case ends when the Instructor 
performs [UC2.5] Cancel/Close Campaign Management Session. 
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rue 2.11 Scenario: New Campaign 


1. In this scenario, the Instructor selects the New button causing 
onButtonNewO to be called on CampaignManagerGUI. 

2. It, in turn, calls CampaignManagerCtl to showAddCampaign(). 

3. CampaignManagerCtl checks if the CampaignGUI is already 
created and isVisible(). It is, then there is already an instance of it active and the scenario 
ends. 


4. If it is not, then it creates a new() instance of CampaignGUI. 

5. It then updates the CampaignGUI with the list of scenarios by 
invoking setScenarios(). 



Figure 39. [UC2.1] Scenario: Add Campaign. 

6. Finally, it calls newCampaignModal() of CampaignGUI to setup 
the GUI as a modal dialog. 

7. The Instructor interacts with the CampaignGUI to edit 
accordingly. Once done, the Instructor selects the OK button, calling onButtonOK() on 
CampaignGUI. If Cancel is selected, then the creation attempt is cancelled and this 
scenario ends. 

8. CampaignGUI next notifies CampaignManagerCtl via 

onNew(). 

9. Consequently, CampaignManagerCtl then creates a new() 
instance of a Campaign. 
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10. And updates it by doing setDescription(). 

11 . And setScenarios(). 

12. This Campaign is then added into the list of campaigns by 
invoking addElement(). 

13. Finally, CampaignManagerCtl updates the 

CampaignManagerGUI by providing the newCampaign(). The scenario then ends. 

[UC 2.21 Scenario: Edit Campaign 



Figure 40. [UC2.2] Scenario: Edit Campaign. 

1. In this scenario, the Instructor selects the Edit button causing 

onButtonEditO of the CampaignManagerGUI to be called. 


2. It then calls CampaignManagerGUI to showEditCampaign(). 

3. CampaignManagerGUI, in turn, checks if CampaignGUI 

isVisiable(). 

4. If it is not, then a new() instance of CampaignGUI is created. 

5. And it updates CampaignGUI by invoking setScenarios(), 
supplying the list of all possible scenarios. 

6. Einally, it calls editCampaignModal() to display the Campaign 
as a modal dialog. 
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7. The Instructor amends the campaign definition accordingly. Once 
completed, the Instruct selects OK, causing onButtonOK() to be called on 
CampaignGUI. If Cancel is selected, the editing is abandoned and the scenario ends. 

8. Else, Campaign will call CampaignManagerCtl to process the 
editing done by calling onEdit(). 

9. CampaignManagerCtl performs the update by starting with a 
renameO on the Campaign object to update its name. 

10. Then it calls setDescription() to update the description. 

11. And lastly, setScenarios() to update the list of scenarios for the 

campaign. 

12. With that done, it proceeds to notify the CampaignManagerGUI 
with editCampaignO to update the campaigns listed, and the scenario ends. 

rue 2.31 Scenario: Delete Campaign 



Top Package::lnstructor 

Figure 41. [UC2.3] Scenario: Delete Campaign. 

1. In this scenario, the Instructor selects the Delete button, causing 

onButtonDeleteO to be called on CampaignManagerGUI. 

2. It then passes this on to CampaignManagerCtl to handle 

onDelete(). 

3. CampaignManagerCtl will removeElement() from the list of 
campaigns. The scenario then ends. 

rue 2.41 Scenario: Save Campaigns 
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Instructor 


Figure 42. [UC2.4] Scenario: Save Campaigns. 

1. In this scenario, the Instructor selects the Save button to save all 
the campaign changes, causing onButtonSave() to be called on 

CampaignManagerGUI. 

2. It, in turn, calls onSave() of CampaignManagerCtl to process it. 

3. CampaignManagerCtl finally calls CampaignCatalogBuilder to 

do the save() itself, and the scenario ends. 



Instructor 


Figure 43. [UC2.5] Scenario: Cancel/Close Campaign Management Session. 

1. In this scenario, the Instructor selects the Cancel button to 
close/cancel the session. This causes onButtonCancel() to be called on the 

CampaignManagerGUI. 

2. CampaignManagerGUI checks with CampaignManagerCtl to 

see if it has been modified(). 

3. If there are changes made which have not been saved, the 
Instructor is asked to verify if the changes should be saved first, ignored, or to cancel the 
cancel/close request altogether. If ignored, then the changes are simply abandoned, and 
we proceed to step 4. If it is cancelled, the scenario ends and the session remain intact. 

Else, CampaignManagerCtl is called to do onSave(). 
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4. 


It then passes the saving to the CampaignCatalogBuilder to 


perform the save(). 

5. The application is then shutdown, ending the scenario. 

Special Requirements 
Nil. 

Pre-conditions 

Nil. 

Post-conditions 

Nil. 

3. [UC.3] Release Campaign 

Brief Description: 

A campaign which is ready for release undergoes an integrity check to 
finalize the campaign package. The campaign is then base-lined and is ready for 
Students to play it. 

Primary Actor(s): 

Instructor. 

Secondary Actor(s): 

Nil. 

Flow of Events 

rUC3.l1 Scenario: Release on New Campaign 



Figure 44. [UC3.1] Scenario: Release on New Campaign. 
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1. The use case begins with the CampaignGUI in the “new 
campaign” mode [UC2.1] with the Instructor selecting the Release button to release the 
campaign. This causes onButtonRelease() to be called against CampaignGUI. 

2. CampaignGUI then performs an integrity check to ensure that all 
the scenarios of the campaign are consistent by calling CampaignManagerCtl to check 
scenarioIntegrityO iteratively for each scenario defined in the campaign. 

3. If all scenario files are intact, it then calls CampaignManagerCtl 
to perform onNewAndRelease(). 

4. CampaignManagerCtl then creates a new() instance of 

Campaign. 

5. And updates Campaign by invoking setDescription(). 

6. As well as setScenarios(). 

7. It then creates a copy for release by creating a new() instance of 

CampaignRelease. 

8. And addScenariosO to it. 

9. It then creates a new() instance of CampaignBuilder. 

10. And asks CampaignBuilder to save() the releasable campaign 
copy. This will include export of all the required files, including the campaign definition 
files and the (copies of) scenario files. 

11. The campaign that was created is then added to Campaigns by 
doing an addElement(). 

12. Finally, it updates CampaignManagerGUI with 
newCampaign(). The scenario then ends. 


rUC3.21 Scenario: Release on Edit Campaign 


1. The use case begins with the CampaignGUI in the “edit campaign” 
mode [UC2.1] with the Instructor selecting the Release button to release the campaign. 
This causes onButtonRelease() to be called against CampaignGUI. 
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2. CampaignGUI then performs an integrity check to ensure that all 
the scenarios of the campaign are consistent by calling CampaignManagerCtl to check 
scenarioIntegrityO iteratively for each scenario defined in the campaign. 

3. If all scenario files are intact, it then calls CampaignManagerCtl 
to do onEditAndReleaseO- 

4. CampaignManagerCtl then renames() the Campaign. 

5. And updates Campaign by invoking setDescription(). 

6. Followed by setScenariosQ. 

7. It then creates a copy for release by creating a new() instance of 

CampaignRelease. 



Figure 45. [UC3.2] Scenario: Release on Edit Campaign. 

8. And addScenariosO to it. 

9. It then creates a new() instance of CampaignBuilder. 

10. And asks CampaignBuilder to save() the releasable campaign 
copy. It will include exporting all the required files, including the campaign definition 
files and the (copies of) scenario files. 

11. Finally, it updates CampaignManagerGUI with editCampaign(). 
The scenario then ends. 

Special Requirements 
Nil. 
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Pre-conditions 


[UC.2] Setup Campaign has to be performed before this, and more 
specifically, either [UC2.1] or [UC2.2] is in progress. 

Post-conditions 

Campaign is now released for Student to play. 

4. [UC.4] Conduct After-Action Review 

Brief Description: 

The Instructor conducts an after-action review with the Student by 
analyzing the event logs. 

Primary Actor(s): 

Instructor. 

Secondary Actor(s): 

CyberCIEGE, Scenario Definition Tool. 

Flow of Events 

Basic Elow 

1. The use case begins with CampaignAnalyzer creating a new() 
instance of CampaignAnalyzerCtl. 

2. CampaignAnalyzerCtl in turn creates a new() instance of 

CampaignAnalyzerGUI. 



Eigure 46. [UC4.0] Basic Elow: Conduct After-Action Review. 

3. CampaignAnalyzer will then call CampaignAnalyzerCtl to 

showGUI(). 
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4. Finally, CampaignAnalyzerCtl will call CampaignAnalyzerGUI 
to showForm(). 

5. From here, the Instructor can interact with the 
CampaignAnalyzerGUI to [UC4.1] Select Campaign, [UC4.2] Examine Details of a 
Scenario, [UC4.3] Play Scenario or [UC4.7] Close the Campaign Analyzer. 


rUC4.l1 Scenario: Select Campaign 



Figure 47. [UC4.1] Scenario: Select Campaign. 

1. In this scenario, the Instructor selects the “Select” button to pick a 
campaign. This causes onButtonSelect() to be called on CampaignAnalyzerGUI. 

2. CampaignAnalyzerGUI will then call CampaignAnalyzerCtl to 
loadCampaign(). 

3. CampaignAnalyzerCtl will create() a new instance of 
CampaignPlayBuilder to collect information about the campaign selected. 

4. It does this by asking CampaignPlayBuilder to load(). 

5. And proceeds to invoke getCampaign() to obtain the campaign 

details. 

6. And also getPlayers() to obtain all the players involved. 

7. It then updates the CampaignAnalyzerGUI by calling 
asetCampaign(). The scenario then ends. 

rUC4.21 Scenario: Examine Details of a Scenario 

1. The scenario begins with the Instructor selecting the “Details” 

button, causing onButtonDetails() to be called on CampaignAnalyzerGUI. 
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2. CampaignAnalyzerGUI then calls CampaignAnalyzerCtl to 
loadScenario(). 

3. CampaignAnalyzerCtl in turn calls CampaignPlay to 
getScenarioEditorCommandO. 

4. Finally, it will execute() the command to launch the Scenario 
Editor Tool with the scenario definition file loaded. The Instructor then proceeds to 
interact with the Scenario Editor Tool, ending this scenario. 



Eigure 48. [UC4.2] Scenario: Examine Details of a Scenario. 

rUC4.31 Scenario: Play Scenario 



Top Package::CyberCIEGE 


Eigure 49. [UC4.3] Scenario: Play Scenario. 

1. In this scenario, the Instructor selects the “Play” button, causing 

onButtonPlayO to be called on the CampaignAnalyzerGUI. 


72 






2. CampaignAnalyzerGUI then calls CampaignAnalyzerCtl to 

playScenario(). 

3. CampaignAnalyzerCtl in turn calls CampaignPlay to 
getPlayNoLogCommandO. 

4. Finally, it will execute() the command to launch CyberCIEGE 
with the given scenario loaded. No event logging is specified in this case. The Instructor 
then interacts with CyberCIEGE to review the scenario selected, ending this scenario. 


rUC4.41 Scenario: View Eog 



Eigure 50. [UC4.4] Scenario: View Eog. 

1. The scenario begins with the Instructor selecting the “View” 
button causing onButtonViewLogO to be called on CampaignAnalyzerGUI. 

2. CampaignAnalyzerGUI in turn calls CampaignAnalyzerCtl to 
viewEventUogO. 

3. Eor each CampaignPlayer, the CampaignAnalyzerCtl will call 
getNameO to compare against the player selected. 

4. Once a match is found, it will create a new() instance of 
PlayerStatus to obtain all the summary status values of that player. 

5. It then creates a new() instance of EventUogGUI. 
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6. And calls EventLogGUI to showDialogO, displaying the event 
log of that player. 

7. The Instructor can continue to interact with the EventLogGUI to 
[UC4.5] Load Saved State and finally to using [UC4.6] Close the Event Log Analyzer to 
end the session. The scenario then ends. 


rUC4.51 Scenario: Load Saved State 



Top Package::CyberCIEGE 


LigureSl. [UC4.5] Scenario: Load Saved State. 

1. In this scenario, the Instructor selects the “Load” button causing 
onButtonLoadO to be called on the EventLogGUI. 

2. EventLogGUI in turn calls CampaignAnalyzerCtl to 

loadSavedStateO. 

3. CampaignAnalyzerCtl then calls CampaignPlayer to 

getPlayLoadSaveGameO, obtaining the command to be executed to load the saved state. 

4. Linally, it will execute() the command, causing CyberCIEGE to be 
launched with the saved game file loaded. The Instructor continues to interact with 
CyberCIEGE to review the state of the player’s game. This scenario then ends. 

rUC4.61 Scenario: Close the Event Log Analyzer 

1. In this scenario, the Instructor selects the “Close” button causing 
onButtonCloseO to be called on the EventLogGUI. 
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2. EventLogGUI will then close() and dispose() itself, ending this 


scenario. 


^ 1 .onButtonClose—► 

Campaign Analyzer::EventLogGUI 





Top Package::lnstructor 

Figure 52. [UC4.6] Scenario: Close the Event Log Analyzer. 

rUC4.71 Scenario: Close the Campaign Analyzer 

1. In this scenario, the Instructor selects the “Close” button causing 
onButtonCloseO to be called on the CampaignAnalyzerGUI. 

2. CampaignAnalyzerGUI will then shutdown the Campaign 

Analyzer. 



1 .onButtonClose—► 


Campaign Analyzer::CampaignAnalyzerGUl| 


Top Package::lnstructor 


Figure 53. [UC4.7] Scenario: Close the Campaign Analyzer. 

Special Requirements 

Nil. 

Pre-conditions 

Nil. 

Post-conditions 

Nil. 

5. [UC.5] Load Campaign 

Brief Description: 

The Student loads the campaign to review the objectives of the campaign, 
and the scenarios to be played. 

Primary Actor(s): 

Student. 

Secondary Actor(s): 

Nil. 
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Flow of Events 

Basic Flow 

1. The use case begins with CampaignPlayerTool creating a new() 
instance of CampaignPlayerTool. 

2. CampaignPlayerCtl is then responsible for creating a new() 
instance of CampaignPlayerGUI. 

3. CampaignPlayerTool will then ask CampaignPlayerCtl to 

showGUIO. 

4. CampaignPlayerCtl in turn calls CampaignPlayerGUI to 

showForm(). 



Figure 54. [UC5.0] Basic Flow: Load Campaign. 

5. The Student can then proceed to perform [UC5.1] Select 

Campaign. 

6. The use case ends when the Student performs [UC5.2] Close 
Campaign Tool. 

rue 5.11 Scenario: Select Campaign 

1. The scenario begins when the Student clicks the Select button, 
causing onButtonSelect() to be called on CampaignPlayerGUI. This enables the 
Student to select a “campaign.xml” file, which is a campaign definition file, to load. 

2. Once selected, it in turns calls CampaignPlayerCtl to 
loadCampaign(). 
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3 . 


CampaignPlayerCtl then creates a new() instance of 

CampaignPlayerBuilder. 

4. And uses it to load() the campaign itself. 

5. CampaignPlayerCtl then retrieves the resulting Campaign object 
by doing a getCampaign() from CampaignPlayerBuilder. 

6. Finally, CampaignPlayerCtl will setCampaign() to the 
CampaignPlayerGUI, updating the display with the campaign details, thus ending the 
scenario. 



Figure 55. [UC5.1] Scenario: Select Campaign. 

rue 5.21 Scenario: Close Campaign Tool 


1. The scenario begins with the Student selecting the Close button. 
This causes onButtonClose() to be called on CampaignPlayerGUI. 


2 . 

scenario. 


CampaignPlayerGUI will then shutdown the tool, thus ending the 



Top Package::Student 


Figure 56. [UC5.2] Scenario: Close Campaign Tool. 

Special Requirements 

Nil. 

Pre-conditions 

Nil. 

Post-conditions 

Nil. 
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6. [UC.6] Play Scenario 

Brief Description: 

The Student proceeds to play a scenario of the campaign. 

Primary Actor(s): 

Student. 

Secondary Actor(s): 

CyberCIEGE. 

Flow of Events 

Basic Elow 

1. The use case begins with the Student having selected a scenario of 
the campaign in [UC5.1]. The Student then selects the Play button, causing 

onButtonPlayO to be called on CampaignPlayerGUI. 

2. It in turn calls the CampaignPlayerCtl to playScenario(). 

3. And CampaignPlayerCtl then calls Campaign to 
getPlayCommando, obtaining an executable shell command to launch CyberCIEGE. 
Einally it executes the command and the Student can proceed to play in CyberCIEGE, 
thus ending the use case. 



Eigure 57. [UC6.0] Basic Elow: Play Campaign. 

Special Requirements 

Nil. 

Pre-conditions 

[UC5.1] must be performed prior to this use case so that the campaign to 
be played is already loaded. 
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Post-conditions 

Nil. 
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APPENDIX C. INTERFACE SPECIFICATIONS WITH 

RIVERMIND 


A. PURPOSE 

The purpose of this appendix is to define the interface specifications with 
Rivermind. 

B. SCENARIO FILE FORMAT 

The following changes/additions proposed for the Scenario File were agreed 

upon: 

1. Title/name (descriptive but short) to the scenario. 

2. Game termination condition settings. Each of these could be optionally 
specified. Only when specified will they affect game termination. For instance, if none 
are specified, the game plays indefinitely. 

a. Upper/lower-bound thresholds for various game play attributes that 
will cause the game to end when the threshold is exceeded. 

b. Game turn limit - game ends when the time unit of game play 
exceeds the limit. 

C. CYBERCIEGE PROGRAM PARAMETERS 

To enable the Campaign Player module to launch CyberCIEGE with the desired 
scenario and generate an EventEog, CyberCIEGE shall support the following program 
parameters: 

CyberCIEGE -s <Scenario Eile> [-i <IDTag>-e <EventLog>] 

To enable a saved game file to be reloaded, the following is required: 
CyberCIEGE -I <Saved Game> 


Program 

Parameter 

Description 

Format 

-s <Scenario File> 

Filename of the scenario to be played. 

Standard filename format. 

-i <IDTag> 

Identifies the campaign-scenario-player for 
this game. The tag <IDTag> (in the form 
<campaign name>/<scenario 

name>/<userID>) is intended to be written 

String of at most 100 
characters. 
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out to the event log file as a header 
information. 


-e <EventLog> 

Name of the event log. CyberCIEGE shall 
append “-999.log” to this name to fully 
qualify the filename. “999” shall be a 
running number starting from “001”, 
increasing by 1 till a maximum of “999”, 
when tbe log is split into multiple log files. 
Ratber than having a single huge event log 
file, it is thus possible to have a number of 
smaller event log files instead. 

String of at most 100 
cbaracters. 

e.g. “example” becomes 
“example-001.log”, “example- 
002.log”, ... 

-1 <Saved Game> 

Load tbe CyberCIEGE saved game file 
supplied. 

Standard filename format. 


Table 5 CyberCIEGE program parameters. 


D. EVENT LOG 

It should be noted that the format is case-sensitive. 


The DTD is defined as follows: 


<!- 

Name: EventLog.dtd 

Version: 1.0 

-> 


<!ELEMENT simsecurityeventlog (version, header. 

(controlevent 1 gameevent 1 

summaryevent 1 userevent 1 

componentevent 1 zoneevent 1 alertevent)*)> 

<!ELEMENT version 

(#PCDATA)> 

<!ELEMENT header 

(idtag?, scenario)> 

<!ELEMENT idtag 

(#PCDATA)> 

<! ELEMENT scenario 

(#PCDATA)> 

<! ELEMENT controlevent 

(dtimereal, dtimegame. 

(debuglog 1 logtrigger 1 popuptrigger 1 tickertrigger 1 savetrigger))> 

<!ELEMENT debuglog 

(tagdata?, message)> 

<! ELEMENT logtrigger 

(tagdata?, message)> 

<! ELEMENT popuptrigger 

(tagdata?, message)> 

<! ELEMENT tickertrigger 

(tagdata?, message)> 

<!ELEMENT savetrigger 

(tagdata?, filename)> 

<!ELEMENT dtimereal 

(#PCDATA)> 

<! ELEMENT dtimegame 

(#PCDATA)> 

<! ELEMENT tagdata 

(#PCDATA)> 

<!ELEMENT message 

(#PCDATA)> 

<!ELEMENT filename 

(#PCDATA)> 

<! ELEMENT gameevent 

(dtimereal, dtimegame. 

(start 1 end 1 pause 1 resume 

1 save 1 exit 1 quit))> 
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<!ELEMENT start 

EMPTY> 

<!ELEMENT end 

(#PCDATA)> 

<! ELEMENT pause 

EMPTY> 

<!ELEMENT resume 

EMPTY> 

<!ELEMENT save 

(filename)> 

<!ELEMENT exit 

EMPTY> 

<!ELEMENT quit 

EMPTY> 

<! ELEMENT summaryevent 

(dtimereal, dtimegame, (daily 1 monthly))> 

<!ELEMENT daily 
cash)> 

(budget, sales, salaries, hardwareexp, softwareexp, misc. 

<! ELEMENT monthly 
cash)> 

(budget, sales, salaries, hardwareexp, softwareexp, misc. 

<!ELEMENT budget 

(#PCDATA)> 

<!ELEMENT sales 

(#PCDATA)> 

<! ELEMENT salaries 

(#PCDATA)> 

<! ELEMENT hardwareexp 

(#PCDATA)> 

<!ELEMENT softwareexp 

(#PCDATA)> 

<! ELEMENT misc 

(#PCDATA)> 

<!ELEMENT cash 

(#PCDATA)> 

<! ELEMENT userevent 

(dtimereal, dtimegame, (hire 1 fire))> 

<!ELEMENT hire 

(name, salary)> 

<!ELEMENT fire 

(name, salary)> 

<! ELEMENT name 

(#PCDATA)> 

<! ELEMENT salary 

(#PCDATA)> 

<! ELEMENT componentevent 

(dtimereal, dtimegame, (buy 1 sell 1 configure))> 

<!ELEMENT buy 

(catalogname, componentname, cost)> 

<!ELEMENT sell 

(catalogname, componentname, cost)> 

<! ELEMENT configure 

(componentname, config?, procsec?)> 

<!ELEMENT config 

((software 1 network 1 configbool 1 configval)*)> 

<! ELEMENT software 

(softwarename, boolean)> 

<! ELEMENT network 

(networkname, boolean)> 

<!ELEMENT configbool 

(field, boolean)> 

<!ELEMENT configval 

(field, value)> 

<! ELEMENT procsec 

( 

(procsecbool 1 procsecval 1 secrecyrange 1 integrityrange 1 access)*)> 

<! ELEMENT procsecbool 

(field, boolean)> 

<! ELEMENT procsecval 

(field, value)> 

<!ELEMENT secrecyrange 

(min?, max?)> 

<! ELEMENT integrityrange 

(min?, max?)> 

<!ELEMENT access 

(user, accessmode)> 

<! ELEMENT catalogname 

(#PCDATA)> 

<! ELEMENT componentname 

(#PCDATA)> 

<!ELEMENT cost 

(#PCDATA)> 

<! ELEMENT softwarename 

(#PCDATA)> 

<! ELEMENT networkname 

(#PCDATA)> 

<!ELEMENT field 

(#PCDATA)> 

<! ELEMENT boolean 

(#PCDATA)> 

<!ELEMENT value 

(#PCDATA)> 
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<!ELEMENT min 

(#PCDATA)> 

<!ELEMENT max 

(#PCDATA)> 

<! ELEMENT accesslist 

(#PCDATA)> 

<!ELEMENT accessmode 

(#PCDATA)> 

<! ELEMENT zoneevent 

(dtimereal, dtimegame. 

zonename, secrecy?, integrity?, physicalsecurity?)> 

<!ELEMENT physicalsecurity 

((physecbool 1 permitteduser)*)> 

<! ELEMENT physecbool 

(field, boolean)> 

<! ELEMENT permitteduser 

(user, boolean)> 

<! ELEMENT zonename 

(#PCDATA)> 

<! ELEMENT secrecy 

(#PCDATA)> 

<! ELEMENT integrity 

(#PCDATA)> 

<! ELEMENT user 

(#PCDATA)> 

<! ELEMENT alertevent 

(dtimereal, dtimegame, (indicator 1 attack))> 

<!ELEMENT indicator 

(securitytarget, targetname, message)> 

<!ELEMENT attack 

(securitytarget, targetname, attacktype, result)> 

<! ELEMENT security target 

(#PCDATA)> 

<! ELEMENT targetname 

(#PCDATA)> 

<! ELEMENT attacktype 

(#PCDATA)> 

<!ELEMENT result 

(#PCDATA)> 


Figure 58. Event Log Document Type Definition. 


The following table details the elements and attributes defined in the XML/DTD 


file. 


Element/ 

Attribute 

Description 

Reqd 

❖ 

Format 

version 

Version of tbe event log format. 

R 

9 [99].9 [99] 
e.g. “1.0” 

header 

Header block. 

R 


idtag 

Tbe idtag associates tbe log file with the 
campaign-scenario-player involved. If the 
idtag is absent, it implies that tbe scenario 
was played independently. 

0 

String of at most 128 characters: 

<campaign name>/<scenario 
name>/<userID 

scenario 

Name of the scenario 

R 

String of at most 128 characters 

control 

event 

Control event block. 

O 


dtimereal 

Date/time of real world. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
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mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

dtimegame 

Date/time of game simulation. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

debuglog 

[controlevent: debuglog] 

For general-purpose debug logging, typically 
generated by CyberCIEGE and is of no 
interest for Campaign Analysis purposes. 

C 


tagdata 

Can be optionally defined by the scenario 
designer to provide data to associate this 
particular log. 

0 

String of at most 256 characters. 

message 

The debug message itself. 

R 

String of at most 1024 characters. 

logtrigger 

[controlevent: logtrigger] 

logtrigger is a control event for scenario- 
defined logging. It is generated when the 
trigger condition is met. 

C 


tagdata 

Can be optionally defined by the scenario 
designer to provide data to associate this 
particular log. 

0 

String of at most 256 characters. 

message 

The log message itself. 

R 

String of at most 1024 characters. 

popup 

trigger 

[controlevent: popuptrigger] 

popuptrigger is a control event for scenario- 
defined popups. It is generated when the 
trigger condition is met. In CyberCIEGE, 
this corresponds to a pop-up dialog 
appearing on the screen. 

C 


tagdata 

Can be optionally defined by the scenario 
designer to provide data to associate this 
particular log. 

0 

String of at most 256 characters. 

message 

The popup message. 

R 

String of at most 1024 characters. 
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tickertrigger 

[controlevent: tickertrigger] 

tickertrigger is a control event for scenario- 
defined ticker messages. It is generated 
when the trigger condition is met. In 
CyherCIEGE, this corresponds to a ticker 
message scrolling across the screen. 

C 


tagdata 

Can he optionally defined hy the scenario 
designer to provide data to associate this 
particular log. 

0 

String of at most 256 characters. 

message 

The ticker message. 

R 

String of at most 1024 characters. 

savetrigger 

[controlevent: savetrigger] 

savetrigger is a control event for scenario- 
defined snapshots. It is generated when the 
trigger condition is met. In CyherCIEGE, 
this corresponds to a game being saved 
without student involvement. Effectively, 
we get a snapshot of the state of the game. 

The initial version of CyherCIEGE will not 
support this feature. Instead, CyherCIEGE 
will cue the student to do a manual save 
instead. 

C 


tagdata 

Can he optionally defined hy the scenario 
designer to provide data to associate this 
particular log. 

0 

String of at most 256 characters. 

filename 

The filename of the saved game. The 
filename provided must he relative to the 
event log directory only. Hence, the 
directory path up to the event log directory 
shall not he included. 

R 

Eilename. 

gameevent 

Game event block. 

O 


dtimereal 

Date/time of real world. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

dtimegame 

Date/time of game simulation. 

R 

YYYYMMDDhhmmss 


86 







YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

start 

Indicates the start of the game - i.e. when the 
student is able to start performing actions. 

This occurs after the scenario has been 
loaded. 

C 

Empty - i.e. contains no value. 

end 

Indicates the result at the end of the game, 
where a game termination condition is 
reached. This is applicable only when the 
scenario has a termination condition. 

C 

“win” 1 “lose” 

pause 

Game was paused. 

c 

Empty - i.e. contains no value. 

resume 

Game resumed following a pause, upon 
completion of saving or upon completion of 
a reload of a previously saved game. 

c 

Empty - i.e. contains no value. 

exit 

Game was exited. May be “resume”d 
subsequently by reloading. 

c 

Empty - i.e. contains no value. 

quit 

Game was terminated before reaching 
termination condition. 

c 

Empty - i.e. contains no value. 

save 

[gameevent: save] 

Game was saved 

0 


filename 

Filename of the saved game. This shall be a 
fully-qualified filename. 

c 

Eilename. 

summary 

event 

Summary event block. 

o 


dtimereal 

Date/time of real world. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

dtimegame 

Date/time of game simulation. 

R 

YYYYMMDDhhmmss 


87 







YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

daily 

[summaryevent : daily] 

Daily summary. Generated at the end of 
each game day (at 2359H). 

C 


budget 

Daily funds budgeted in $. 

R 

Dollar amount. 

sales 

Daily sales in $. 

R 

Dollar amount. 

salaries 

Daily salaries paid in $. 

R 

Dollar amount. 

hardware 

exp 

Hardware bought today in $. 

R 

Dollar amount. 

software 

exp 

Software bought today in $. 

R 

Dollar amount. 

misc 

Misc daily fixed costs in $. 

R 

Dollar amount. 

cash 

Current cash balance in $. Cash balance 
should be = (budget + sales) - (salaries + 
hardwareexp + softwareexp + misc) 

R 

Dollar amount. 

monthly 

[summaryevent : monthly] 

Monthly summary. Generated at the end of 
each game month (at 2359H of the last day 
of the month). 

An initial monthly summary is to be 
generated immediately before the “game”- 
“start” event is logged. This is to indicate 
the start state. 

C 


budget 

Monthly budget in $. 

R 

Dollar amount. 

sales 

Monthly sales in $. 

R 

Dollar amount. 

salaries 

Monthly salaries paid in $. 

R 

Dollar amount. 

hardware 

exp 

Hardware bought this month in $. 

R 

Dollar amount. 

software 

exp 

Software bought this month in $. 

R 

Dollar amount. 

misc 

Misc fixed costs for this month $. 

R 

Dollar amount. 


88 








cash 

Current cash balance in $. Cash balance 
should be = (budget + sales) - (salaries + 
hardwareexp + softwareexp + misc) 

R 

Dollar amount. 

userevent 

User event block. 

O 


dtimereal 

Date/time of real world. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

dtimegame 

Date/time of game simulation. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

hire 

[userevent: hire] 

User hired. 

C 


name 

Name of user. 

R 

String of at most 64 characters. 

salary 

Salary of user in $. 

R 

Dollar amount. 

fire 

[userevent: fire] 

User fired. 

C 


name 

Name of user. 

R 

String of at most 64 characters. 

salary 

Salary of user in $. 

R 

Dollar amount. 

component 

event 

Component event block. 

O 


dtimereal 

Date/time of real world. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 
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dtimegame 

Date/time of game simulation. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

buy 

[componentevent: buy] 

Component bought. 

C 


catalog 

name 

Catalog name that this component is an 
instance of. 

R 

String of at most 64 characters 

component 

name 

Name of component bought. 

R 

String of at most 64 characters. 

cost 

Cost of the component in $. 

R 

Dollar amount. 

sell 

[componentevent: sell] 

Component sold. 

C 


catalog 

name 

Catalog name that this component is an 
instance of. 

R 

String of at most 64 characters 

component 

name 

Name of component sold. 

R 

String of at most 64 characters. 

cost 

Cost of the component in $. 

R 

Dollar amount. 

configure 

[componentevent: configure] 

Component being configured. 

C 


component 

name 

Name of the component being configured. 

R 

String of at most 64 characters. 

config 

[componentevent: configure : config] 

Configuration setup group. 

0 


software 

[componentevent: configure : config : 
software] 

Software configuration. 

C 


software 

name 

Name of the software. 

R 

String of at most 64 characters. 

boolean 

Indicates whether the software is being 

R 

“true” 1 “false” 
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installed (“true”) or uninstalled (“false”). 



network 

[componentevent: configure : config : 
network] 

C 


network 

name 

Name of the network. 


String of at most 64 characters. 

boolean 

Indicates whether the component is being 
attached (“true”) or detached (“false”) from 
the network. 


“true” 1 “false” 

configbool 

[componentevent: configure : config : 
configbool] 

Configuration setting which is a boolean 
type. 

C 


field 

Name of the configuration setting. 

e.g.: 

‘ ‘Remote Authentication” 1 
‘ ‘ AcceptPKICerts” 1 
‘ ‘U seOneT imePass wordT oken” 1 
“UseB iometrics” 1 
“UseTokenPKICerts”! 

“UseClientPKICerts”! 

“VPNClient”! 

“ScanEmailAttachments”! 
“StripEmailAttachments” 1 
‘ ‘ AutomaticLockLogout” 1 
“SelfAdminister”! 

“SelfAdministerMAC”! 
“AdministerSoftwareControl”! 
“BlockRemovableMedia” 1 
“BlockLocalStorage”! 

“BrowserSettingLoose” 1 
“BrowserSettingNormal”! 
“BrowserSettingStricf ’ 1 
“EmailSettingsLoose” 1 
“EmailSettingsNormal” 1 
“EmailSettingsStrict”! 

‘ ‘UpdatePatches AsReleased” 1 
“UpdatePatchesRoutinely” 1 
‘ ‘UpdatePatches Automatically” 1 
“UpdateAntivirusRegular”! 
“UpdateAntivirusAutomatic”! 
“UninterruptiblePower”! 

“AdminBackup”! 

“OffsiteBackup” 

R 

String of at most 64 characters. 
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boolean 

Indicates whether the configuration setting is 
being applied (“true”) or removed (“false”). 

R 

“true” 1 “false” 

configval 

[componentevent: configure : config : 
configval] 

Configuration setting which is a value-based 
type. 

C 


field 

Name of the configuration setting. 

e.g. 

“PasswordLength” 1 
“ChangeFrequency” 1 
“PasswordCompIexity” 1 

R 

String of at most 64 characters. 

value 

V alue of the configuration setting. Note that 
there are valid values associated with each 
specific field. 

R 

String of at most 64 characters. 

procsec 

[componentevent: configure : procsec] 

Procedural security. 

0 


procsecbool 

[componentevent: configure : procsec : 
procsecbool] 

Procedural security setting which is a 
boolean type. 

C 


field 

Name of the procedural security. 

e.g.: 

“HoIdsUser Asset” 1 
“ProtectWithACL” 1 
“WriteDownPasswords” 1 
“LockerLogoff ’ 1 
“NoEmailAttachmentExecute” 1 
“NoExternalSoftware” 1 
“NoUseOfModems” 1 
“NoWebMail” 1 
“NoMediaLeaveZone” 1 
“UpdateAntiVirus” 1 
“ApplyPatches” 1 
“LeaveMachinesOn” 1 
“NoPhysicalModifications” 1 
“UserBackup” 

R 

String of at most 64 characters. 

boolean 

Indicates whether the procedural security is 
being applied (“true”) or removed (“false”). 

R 

“true” 1 “false” 
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procsecval 

[componentevent: configure : procsec : 
procsecval] 

Procedural security setting which is a value- 
hased type. 

C 


field 

Name of the procedural security. 

e.g. 

“PasswordLength” 1 
“PasswordCharacterSet” 1 
“PasswordChangeFrequency” 1 

R 

String of at most 64 characters. 

value 

V alue of the procedural security. Note that 
there are valid values associated with each 
specific field. 

R 

String of at most 64 characters. 

secrecy 

range 

[componentevent: configure : procsec : 
secrecyrange] 

Secrecy range. 

C 


min 

Minimum secrecy level. 

R 

String of at most 64 characters. 

max 

Maximum secrecy level. 

R 

String of at most 64 characters. 

integrity 

range 

[componentevent: configure : procsec : 
integrityrange] 

Integrity range. 

C 


min 

Minimum integrity level. 

R 

String of at most 64 characters. 

max 

Maximum integrity level. 

R 

String of at most 64 characters. 

access 

[componentevent: configure : procsec : 
access] 

Access rights to the component (accesslist). 

C 


user 

Name of user or group. 


String of at most 64 characters. 

accessmode 

Access mode is specified hy 4 attributes of 
read, write, control and execute. 


AAAA 

Each A can he “Y”es, “N”o or 
“X” for don’t care. 

e.g. “YYXX” has read and write. 
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but control and execute are don’t 

care. 

zoneevent 

Zone event block. 

O 


dtimereal 

Date/time of real world. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

dtimegame 

Date/time of game simulation. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

zonename 

Name of the zone. 

R 

String of at most 64 characters. 

secrecy 

Intended secrecy level for people entering 
the zone. 

0 

String of at most 64 characters. 

integrity 

Intended integrity level for people entering 
the zone. 

0 

String of at most 64 characters. 

physical 

security 

[zoneevent: physicalsecurity] 

Physical security measures applied to the 
zone. 

0 


physecbool 

[zoneevent: physicalsecurity : physechool] 

Physical security measure setting of a 
boolean type. 



field 

Name of the physical security measure. 

e.g. 

“Receptionist”! “GuardAtDoor”! 

‘ ‘PatrollingGuard” 1 
“ProhibitMedia” 1 
‘ ‘ProhibitPhoneDe vices” 1 
‘ ‘ExpensivePerimeter Alarms” 1 
‘ ‘ModeratePerimeter Alarms” 1 
‘ ‘ReinforcedW alls” 1 

R 

String of at most 64 characters. 
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“SurveillanceCameras”! 

“PermitEscortedVisitors”! 

‘ ‘V isualPeoplelnspection” 1 
“XrayPackages”! 

“KeyLockOnDoor”! 

“Cipher LockOnDoor” 1 
“ExpensiveMsScanner”! 
“ModeratelrisScanner” 1 
“Badges” 



boolean 

Indicates whether the physical security 
measure is being applied (“true”) or not 
(“false”). 

R 

“true” 1 “false” 

permitted 

user 

[zoneevent: physicalsecurity : 
permitteduser] 

Permitted users to a zone. 

0 


user 

Name of user or group. 

R 

String of at most 64 characters. 

boolean 

Indicates whether the user is being added 
(“true”) or removed (“false”) from the list of 
permitted personnels for entering the zone. 

R 

“true” 1 “false” 

alertevent 

Alert event block. 

O 


dtimereal 

Date/time of real world. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

dtimegame 

Date/time of game simulation. 

R 

YYYYMMDDhhmmss 

YYYY = Year 

MM = Month (“01” to “12” 

DD = Day (“01” to “31”) 
hh = Hour (“00 to 23”) 
mm = Minutes (“00” to “59”) 
ss = Seconds (“00” to “59”) 

indicator 

[alertevent: indicator] 

Indicator of a possible ongoing attack 
(including false positives). 

C 


security 

Security target that the indicator pertains to. 

R 

“zone” 1 “component” 
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target 

e.g. “zone”, “component”, ... 



targetname 

Name of the target. 

R 

String of at most 64 characters. 

message 

The indicator message (which is also 
displayed to the student in CyberCIEGE). 

R 

String of at most 1024 characters. 

attack 

[alertevent: attack] 

C 



Actual attack that was generated by 
CyberCIEGE. This represents the actual 
occurrence of the attack that is not revealed 
to the student in CyberCIEGE, in contrast to 
the indicator. 



security 

target 

Security target that the indicator pertains to. 
e.g. “zone”, “component”, ... 

R 

“zone” 1 “component” 

targetname 

Name of the target. 

R 

String of at most 64 characters. 

attacktype 

Type of attack (refer to “Legal Attacker 
Moves” document). 

R 

String of at most 1024 characters. 

result 

Result of the attack - whether was it 
successful (“true”) or if the defensive 
measures were successful in stopping it 
(“false”). 

R 

“true” 1 “false” 


• Reqd - indicates whether the element is (R)equired or (O)ptional within the parent block. 
(C)hoice implies that at least one of the elements must appear within the block. 

• Dollar amount is specified in the form 9[9...]. e.g. $25 is “25”, $1,200 is “1200”. 

Table 6 Element/attribute description. 
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APPENDIX D. INTERFACE SPECIFICATIONS WITH KEN 
JOHNS (SCENARIO DEFINITION TOOL) 


A. PURPOSE 

The purpose of this appendix is to define the interface specifications with Ken 
John’s thesis effort which aims to develop the Scenario Definition Tool. 

B. TAXONOMY FILE FORMAT 

The Taxonomy terms are defined as hierarchical relationships. The XML format 
is a convenient syntax for representing such a structure. Defined here is the DTD for this 
purpose: 

Name: Taxonomy, dtd 

Version: 1.0 
-> 

<!ELEMENT simsecuritytaxonomy (tnode)*> 

<!EEEMENT tnode (tname, (tnode)*)> 

<!EEEMENT tname _ (#PCDATA)> _ 

Eigure 59. Taxonomy Document Type Definition. 

The XME data file holding the Taxonomy terms are stored in the corresponding 

Taxonomy.xml file. An example is shown as follows: 

<?xml version=”1.0” encoding=”UTE-8”?> 

<!DOCTYPE simsecuritytaxonomy SYSTEM “Taxonomy.dtd”> 

<simsecuritytaxonomy> 

<tnode> 

<tname>Encryption</tname> 

<tnode> 

<tname>Public Key Encryption</tname> 

<tnode> 

<tname>RSA</tname> 

</tnode> 

</tnode> 

<tnode> 

<tname>Symmetric Key Encryption</tname> 

</tnode> 

</tnode> 

<tnode> 

<tname>E-voting</tname> 

</tnode> 
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</simsecuritytaxonomy> 

Figure 60. Taxonomy.xml sample. 

C. EMBEDDED TAXONOMY TAGS 

When Scenario Definition Files are created, scenario tagging can be optionally 
performed. This is done by selecting Taxonomy terms from the Taxonomy.xml file. The 
Taxonomy terms can be embedded anywhere within the Scenario Definition File, 
prefixed by comments (i.e. “//”). Each Taxonomy term is bounded by a 
“TaxonomyTag:” prefix and “:end” suffix pair as shown below: 

// TaxonomyTag: Taxonomy Term #1 :end 
// TaxonomyTag: Taxonomy Term #2 :end 

Figure 61. Embedded Taxonomy tags. 

D. SCENARIO EDITOR PROGRAM PARAMETERS 

To enable the Campaign Analyzer to review the scenario definition, the Scenario 
Definition Tool will need to support the following program parameters: 

ScenarioDefinitionTool -s <Scenario File> 

This loads the given <Scenario Pile> into the the Scenario Definition Tool to 
enable the Instructor to review the details. 


Program 

Parameter 

Description 

Format 

-s <Scenario File> 

Filename of the scenario to be loaded. 

Standard filename format. 
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APPENDIX E. SOURCE CODES 


A. PURPOSE 

The purpose of this appendix is to list the source code and configuration 
filenames for the application modules developed. The sections are organized according 
to the directory structure of the Java source codes and configuration files. 

Each application module is placed in a separate directory. In addition, base 
classes and utility classes are stored in the “Utility” directory. Configuration files are 
stored in a separate “bin” directory. A brief description of each file is provided. 

B. TAXONOMY MANAGER 


Filename 

Description 

T axonomyManager .j ava 

The main program class for the Taxonomy Manager 

module. 

T axonomyCtl.j ava 

Controller (control object) for the Taxonomy 

Manager. 

T axonomyGUI.j ava 

Main GUI (boundary object) for the Taxonomy 

Manager. 

TaxonomyBuilder.java 

Builder class for reading/writing to the 

Taxonomy.xml. 

Taxonomy.] ava 

Taxonomy (entity object). 


Table 7 Taxonomy Manager source codes. 


C. CAMPAIGN MANAGER 


Filename 

Description 

CampaignManager .j ava 

The main program class for the Campaign Manager 

module. 

CampaignManagerCtl.j ava 

Controller (control object) for the Campaign 

Manager. 
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CampaignManagerGUI.j ava 

Main GUI (boundary ob]ect) for the Campaign 

Manager. 

CampaignGUI.j ava 

GUI (boundary ob]ect) for editing a campaign. 

ScenarioFilterGUI.j ava 

GUI (boundary ob]ect) for defining the filter. 

CampaignCatalogBuilder.java 

Builder class for reading/writing to the 

CampaignCatalog.xml. 

CampaignBuilder.java 

Builder class for exporting a campaign to a folder. 

C ampaignRelease .j av a 

Stores the campaign data for a releasable 

campaign (entity ob]ect). 

Campaign.] ava 

Stores the campaign data (entity object) for a 

campaign being edited. 

Scenario.] ava 

Stores the scenario data. 

ScenarioCatalogB uilder.] ava 

Builder class to recursively parse and assemble a list 

of available scenarios. 


Table 8 Campaign Manager source codes. 

D. CAMPAIGN PLAYER 


Filename 

Description 

CampaignPlayerTool.java 

The main program class for the Campaign Player 

module. 

CampaignPlayerCtL] ava 

Controller (control object) for the Campaign Player. 

CampaignPlayerGUI.] ava 

Main GUI (boundary object) for the Campaign 

Player. 

XMLFilter.java 

XML filter. 

CampaignPlayBuilder.java 

Builder class for reading a campaign.xml file. 

CampaignPlayer.] ava 

Defines a student (entity object). 

CampaignPlay.] ava 

Defines a campaign being played (entity object). 
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ScenarioPlay.j ava 

Defines a scenario being played (entity object). 

ScenarioDefinitionFile .j ava 

Defines a scenario definition (entity object). 


Table 9 Campaign Player source codes. 

E. CAMPAIGN ANALYZER 


Filename 

Description 

CampaignAnalyzer .j ava 

The main program class for the Campaign Analyzer 

module. 

CampaignAnalyzerCtl.j ava 

Controller (control object) for the Campaign 

Analyzer. 

CampaignAnalyzerGUI.j ava 

Main GUI (boundary object) for the Campaign 

Analyzer which provides a campaign-level summary 

view of student event logs. 

EventLogGUI. j ava 

GUI for the Event Log Analyzer which presents the 

detailed event log of a single student. 

EventT ableModel.j ava 

A model for holding a table structure of logged 

events. 

PropertyTableModel.j ava 

A model for holding a table structure of the sub¬ 
events. 

StudentTableModel.j ava 

A model for holding a table structure of student 

data. 

ScenarioEventLog.java 

Defines a Scenario Event Log Eile (entity object). 

LogEvent.java 

Defines a single log event (entity object). 

Player Status.java 

Maintains the summary status values of a student for 

a given scenario. 


Table 10 Campaign Analyzer source codes. 
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F. UTILITY 


Filename 

Description 

CampaignResource .j ava 

Utility class to handle resource property definitions 

CustomDateT ime .j ava 

A customized date/time class to handle the date/time 

formats used. 

Helper.] ava 

A singleton class providing miscellaneous useful 

functions. 

SDFilenameFilter.j ava 

FilenameFilter class for Scenario Definition Files. 

StdT ableModel.j ava 

Base class for the TahleModel used in JTahle. 

XMLBuilder.j ava 

Base class for XML-hased builder classes. 

XMLFilter.java 

Implements a FileFilter for XML files (i.e. *.xml). 

XMLHelper.java 

Defines various XML-related constants. 

StringV ector.j ava 

Implements a Vector class of String objects. 

Table 11 Util 

ity and base classes. 


G. BIN 


Filename 

Description 

Campaign.properties 

The resource property definitions 

Taxonomy, dtd 

DTD for the Taxonomy data. 

Taxonomy, xml 

XML file to store the Taxonomy hierarchy. 

CampaignCatalog.dtd 

DTD for the catalog of campaigns. 

CampaignCatalog.xml 

XML file to store the catalog of campaigns. 

CampaignRelease.dtd 

DTD for released campaigns. 

EventLog.dtd 

DTD for the event log file. 


DTD: Document Type Definition; XML: Extensible Mark-up Language. 
Table 12 Resource files. 
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